Forem: Verkkokauppa.com

How to: Kubernetes for Cheap on Google Cloud

Niko Kosonen — Tue, 03 Mar 2020 07:08:10 +0000

[TL;DR: Run Kubernetes on two micro instances on GKE without external load balancers. Cluster setup from scratch. github.com/nkoson/gke-tutorial]

My excitement of running kubernetes on Google Cloud Platform was quickly curbed by the realization that, despite Google's virtual machines starting at affordable price points, their network ingress is another story: Let's say you want to set up a simple cluster for your own personal projects, or a small business. At the time of writing, a couple of micro nodes running in Iowa will set you back $7.77/mo, but the only (officially marketed, AFAIK) method of getting traffic in is by using a load balancer - which start at whopping $18.26 for the first 5 forwarding rules. That is a deal breaker for me, since there are plenty of other cloud providers with better offerings to smaller players.

That's when I stumbled upon a great article about running a GKE cluster without load balancers. With this newly incited motivation, I set out to create my GKE cluster - with the requirement of it being as cheap as possible while enjoying a key benefit of the cloud: being free of manual maintenance.

I have composed this article as a step-by-step tutorial. Based on my own experience in setting up a cluster on a fresh GCP account, I try to cover every topic from configuring the infrastructure to serving HTTP(S) requests from inside the cluster. Please notice, that I did this mainly to educate myself on the subject, so critique and corrections are wholeheartedly welcome.

We'll be using Terraform.io to manage our cloud infrastructure, so go ahead and register an account, if you haven't already. You'll obviously need access to a Google Cloud Platform account, as well.

Let’s get going by creating a new project on the GCP console:

Project selector (top bar) -> New Project -> Enter name -> Create

This will create a nice empty project for us, which differs from the default starter project in that the newly created blank doesn’t come with any predefined API’s or service accounts.
We’ll start digging our rabbit hole by enabling the Compute Engine API, which we need to communicate with GCP using Terraform. We'll also enable the Service Usage API so that Terraform can enable services for us as we go forward.

APIs & Services -> API Library -> Compute Engine API -> Enable

APIs & Services -> API Library -> Service Usage API -> Enable

Once the APIs have been initialized, we should find that GCP has generated a new service account for us. The aptly named Compute Engine default service account grants us remote access to the resources of our project.
Next, we’ll need to create a key for Terraform to authenticate with GCP:

IAM & Admin -> Service accounts -> Compute Engine default service account -> Create key -> Create as JSON

The key that we just downloaded can be used in our terraform.io console as an environment variable, or directly from local disk when running Terraform CLI commands. The former requires newlines edited out of the JSON file and the contents added as GOOGLE_CLOUD_KEYFILE_JSON in our terraform.io workspace:

Workspaces -> (select a workspace) -> Variables -> Environment Variables

Make sure you set the value as “sensitive / write only”, if you decide to store the key in your terraform.io workspace.
As stated above, it’s also possible to read the key from your local drive by adding the following in the Terraform provider resource:

provider "google" {
  version = "3.4.0"
  credentials = file("<filename>.json")
}

In this tutorial, we’ll be using the latter of the two methods.

While we’re here, it’s worth noting that the Compute Engine default service account doesn’t have the permissions to create new roles and assign IAM policies in the project. This is something that we will need later as part of our terraforming process, so let’s get it over with:

IAM & admin -> edit Compute Engine default service account (pen icon) -> Add another role -> select "Role Administrator" -> Save

Add another role -> select "Project IAM Admin" -> Save

Add another role -> select "Service Account Admin" -> Save

We’re now ready to initialize Terraform and apply our configuration to the cloud.

terraform init

This will set up your local Terraform workspace and download the Google provider plugin, which is used to configure GCP resources.

We can proceed to apply the configuration to our GCP project.

terraform apply

This will feed the configuration to the terraform.io cloud, check its syntax, check the state of our GCP project and, finally, ask for confirmation to apply our changes. Enter ‘yes’ and sit back. This is going to take a while.

module.cluster.google_project_iam_custom_role.kluster: Creating...
module.cluster.google_service_account.kluster: Creating..
module.cluster.google_compute_network.gke-network: Creating...
module.cluster.google_compute_address.static-ingress: Creating...
module.cluster.google_service_account.kubeip: Creating...
module.cluster.google_container_node_pool.custom_nodepool["ingress-pool"]: Creating...

module.cluster.google_container_node_pool.custom_nodepool["ingress-pool"]: Creation complete after 1m8s

Once the dust has settled, it’s time to check the damage. We set out to configure a minimal cloud infrastructure for running a kubernetes cluster, so let’s see how we’ve managed so far.

Compute Engine -> VM Instances

This page reveals that we now have two virtual machines running. These machines are part of node pools ingress-pool and web-pool. A node pool is a piece of configuration, which tells Google Container Engine (GKE) how and when to scale the machines in our cluster up or down. You can find the node pool definitions in cluster.tf and node_pool.tf

If you squint, you can see that the machines have internal IP addresses assigned to them. These addresses are part of our subnetwork range. There is a bunch of other address ranges defined in our cluster, which we’ll glimpse over right now:

subnet_cidr_range = "10.0.0.0/16"
# 10.0.0.0 -> 10.0.255.255

Defined in google_compute_subnetwork, this is the address range of the subnetwork, in which our GKE cluster will run.

master_ipv4_cidr_block = "10.1.0.0/28"
# 10.1.0.0 -> 10.1.0.15

The master node of our kubernetes cluster will be running under this block, used by google_container_cluster.

cluster_range_cidr = "10.2.0.0/16"
# 10.2.0.0 -> 10.2.255.255

Rest of our kubernetes nodes will be running under this range, defined as a secondary range as part of our subnet.

services_range_cidr = "10.3.0.0/16"
# 10.3.0.0 -> 10.3.255.255

Also a secondary range in our subnet, the service range contains our kubernetes services, more of which a bit later.

Understanding the basic building blocks of our network, there are a couple more details that we need to grasp in order for this to make sense as a whole. The nodes in our cluster can communicate with each other on the subnet we just discussed, but what about incoming traffic? After all, we’ll need to not only accept incoming connections, but also download container images from the web. Enter Cloud NAT:

Networking -> Network Services -> Cloud NAT

Part of our router configuration, Cloud NAT grants our VM instances Internet connectivity without external IP addresses. This allows for a secure way of provisioning our kubernetes nodes, as we can download container images through NAT without exposing the machines to public Internet.
In our definition, we set the router to allow automatically allocated addresses and to operate only on our subnetwork, which we set up earlier.

OK, our NAT gives us outbound connectivity, but we’ll need a inbound address for our cheap-o load balancer / ingress / certificate manager all-in-one contraption, traefik. We’ll talk about the application in a while, but let’s first make sure that our external static IP addresses are in check:

Networking -> VPC network -> External IP addresses

There should be two addresses on the list; an automatically generated one in use by our NAT, plus another, currently unused address which is named static-ingress. This is crucial for our cluster to accept connections without an external load balancer, since we can route traffic through to our ingress node using a static IP.
We’ll be running an application, kubeip, in our cluster to take care of assigning the static address to our ingress node, which we’ll discuss in a short while.

This is a good opportunity to take a look at our firewall settings:

Networking -> VPC network -> Firewall rules

We have added a single custom rule, which lets inbound traffic through to our ingress node. Notice, how we specify a target for the rule to match only with instances that carry the ingress-pool tag. After all, we only need HTTP(S) traffic to land on our internal load balancer (traefik). The custom firewall rule is defined here.

Lest we forget, one more thing: We'll be using the CLI tool gcloud to get our kubernetes credentials up and running in the next step. Of course, gcloud needs a configuration of its own, as well, so let's get it over with:

gcloud init

Answer truthfully to the questions and you shall be rewarded with a good gcloud config.

Kubernetes

Our cloud infrastructure setup is now done and we're ready to run some applications in the cluster. In this tutorial, we'll be using kubectl to manage our kubernetes cluster. To access the cluster on GCP, kubectl needs a valid config, which we can quickly fetch by running:

gcloud container clusters get-credentials <cluster> --region <region>

Aggressive optimizations

Disclaimer: I don't recommend doing any of the things I've done in this section. Feel free to crank up the node pool machine types to something beefier (such as g1-small) in favor of keeping logging and metrics alive. At the time of writing this tutorial, I had to make some rather aggressive optimizations on the cluster to run everything on two micro instances. We did mention being cheap, didn't we?

Realizing that it's probably not a good idea to disable logging, we have disabled logging on GCP. Now that we're up to speed, why don't we go ahead and turn off kubernetes metrics as well:

kubectl scale --replicas=0 deployment/metrics-server-v0.3.1 --namespace=kube-system

That's over 100MB of memory saved on our nodes at the expense of not knowing the total memory and CPU consumption anymore. Sounds like a fair deal to me!
We'll scale kube-dns service deployments down as well, since running multiple DNS services in our tiny cluster seems like an overkill:

kubectl scale --replicas=0 deployment/kube-dns-autoscaler --namespace=kube-system
kubectl scale --replicas=1 deployment/kube-dns --namespace=kube-system

kubernetes default-backend can go too. We'll be using nginx for this purpose:

kubectl scale --replicas=0 deployment/l7-default-backend --namespace=kube-system

At this point I realized that the instance spun up from web-pool was stuck at "ContainerCreating" with all the kubernetes deployments I just disabled still running, so I just deleted the instance to give it a fresh start:

gcloud compute instances list
gcloud compute instances delete <name of the web-pool instance>

After a few minutes, GCP had spun up a new instance from the web-pool instance pool, this time without the metrics server, default backend and with only one DNS service.

Deployments

The cluster we're about to launch has three deployments: nginx for serving web content, kubeIP for keeping our ingress node responsive and traefik which serves a dual purpose; routing incoming connections to nginx, plus handling SSL. We'll discuss each deployment next.

nginx-web

Incoming HTTP(S) traffic in our cluster is redirected to the nginx server, which we use as our web backend. Put simply in kubernetes terms, we're going to deploy a container image within a namespace and send traffic to it through a service. We'll do namespace first. Navigate to k8s/nginx-web/ and run:

kubectl create --save-config -f namespace.yaml

Pretty straightforward so far. The namespace we just created is defined here. Next up is the deployment:

kubectl create --save-config -f deployment.yaml

As you can see from the definition, we want our deployment to run under the namespace nginx-web. We need the container to run on a virtual machine that's spun up from the node pool web-pool, hence the nodeSelector parameter. We're doing this because we want to run everything except the load balancer on a preemptible VM to cut down costs while ensuring maximum uptime.

Moving on, the container section defines a Docker image we want to run from our private Google Container Registry (GCR) repository. Below that, we open the ports 80 and 443 for traffic and set up health check (liveness probe) for our container. The cluster will now periodically GET the container at the endpoint /health and force a restart if it doesn't receive a 200 OK response within the given time. Readiness probe is basically the same, but will tell the cluster when the container is ready to start accepting connections after initialization.

We won't dive too deep into Docker in this tutorial, but we have included a basic nginx:alpine container with placeholder web content in this tutorial. We'll need to upload the container image to GCR for kubernetes to use it as per the deployment we just created. Navigate to docker/nginx-alpine and run:

docker build -t eu.gcr.io/<project>/nginx-web .

This builds the image and tags it appropriately for use in our cluster. We need docker to authenticate with GCP, so let's register gcloud as docker's credential helper by running:

gcloud auth configure-docker

To push the image into our registry, run:

docker push eu.gcr.io/<project>/nginx-web

We can check that everything went fine with the deployment by running:

kubectl get event --namespace nginx-web

LAST SEEN  TYPE      REASON              KIND   MESSAGE
1m         Normal    Pulling             Pod    pulling image "eu.gcr.io/gke-tutorial-xxxxxx/nginx-web:latest"
1m         Normal    Pulled              Pod    Successfully pulled image "eu.gcr.io/gke-tutorial-xxxxxx/nginx-web:latest"
1m         Normal    Created             Pod    Created container
1m         Normal    Started             Pod    Started container

We now have an nginx container running in the right place, but we still need to route traffic to it within the cluster. This is done by creating a service :

kubectl create --save-config -f service.yaml

Our service definition is minimal: We simply route incoming traffic to applications that match the selector nginx-web. In other words, traffic that gets sent to this service on ports 80 and 443 will get directed to pods running our web backend.

kubeIP

Working in a cloud environment, we cannot trust that our virtual machines stay up infinitely. In contrary, we actually embrace this by running our web server on a preemptible node. Preemptible nodes are cheaper to run, as long as we accept the fact that they go down for a period of time at least once a day.
We could easily ensure higher availability in our cluster by simply scaling up the number of nodes, but for the sake of simplicity, we'll stick to one of each type, defined by our node pools ingress-pool and web-pool

A node pool is a set of instructions on how many and what type of instances we should have running in our cluster at any given time. We'll be running traefik on a node created from ingress-pool and the rest of our applications run on nodes created from web-pool.

Even though the nodes from ingress-pool are not preemptible, they might restart some time. Because our cheap-o cluster doesn't use an external load balancer (which is expen\$ive), we need to find another way to make sure that our ingress node always has the same IP for connectivity.
We solve this issue by creating a static IP address and using kubeip to bind that address to our ingress node when necessary.

Let's create the deployment for kubeip by navigating to k8s/kubeip and running:

kubectl create --save-config -f deployment.yaml

We define kube-system as the target namespace for kubeip, since we want it to communicate directly with the kubernetes master and find out when a newly created node needs a static address. Using a nodeSelector, we force kubeip to deploy on a web-pool node, just like we did with nginx earlier.

Next in the config we define a bunch of environment variables, which we bind to values in a ConfigMap. We instruct our deployment to fetch GCP service account credentials from a kubernetes secret. Through the service account, kubeip can have the required access rights to make changes (assign IPs) in GCP.

We created a GCP service account for kubeip as part of our Terraform process. Now we just need to extract its credentials just like we did with our main service account in the beginning of this tutorial. For added variety, let's use the command line this time. From the root of our project, run:

gcloud iam service-accounts list
gcloud iam service-accounts keys create keys/kubeip-key.json --iam-account <kubeip service-account id>

Now that we have saved the key, we'll store it in the cluster as a kubernetes secret:

kubectl create secret generic kubeip-key --from-file=keys/kubeip-key.json -n kube-system

We have created a GCP service account for kubeip and configured kubeip to access it via the kubernetes secret. We will still need a kubernetes service account to access information about the nodes in the cluster. Let's do that now:

kubectl create --save-config -f serviceaccount.yaml

We define a (kubernetes) ServiceAccount and below it the ClusterRole and ClusterRoleBinding resources, which define what our service account is allowed to do and where.

Next, we need to create the ConfigMap for the deployment of kubeip:

kubectl create --save-config -f configmap.yaml

In the config, we set kubeip to run in web-pool and watch instances spun up from ingress-pool. When kubeip detects such an instance, it checks if there is an unassigned IP address with the label kubeip and value static-ingress in the reserve and gives that address to the instance. We have restricted the ingress-pool to a single node, so we only need a single static IP address in our reserve.

traefik

External load balancers are very useful in keeping your web service responsive under high load. They are also prohibitively expensive for routing traffic to that single pod in your personal cluster, so we're going to make do without one.

In our tutorial cluster, we dedicate a single node to hosting traefik, which we configure to route traffic to our web backend (nginx server). Traefik can also fetch SSL certificates from resolvers such as letsencrypt to protect our HTTPS traffic. We're not going to cover procuring a domain name and setting up DNS in this tutorial, but, for reference, I have left everything that's required for setting up a DNS challenge commented out in the code.

Let's create a namespace and a service account for traefik. Navigate to k8s/traefik and run:

kubectl create --save-config -f namespace.yaml

kubectl create --save-config -f serviceaccount.yaml

Next, we'll create the deployment and take a look at what we've done so far:

kubectl create --save-config -f deployment.yaml

Using a nodeSelector once again, we specify that we want traefik to run on a machine that belongs to ingress-pool, which means that in our cluster, traefik will sit on a different machine than kubeip and nginx. The thought behind this is that both of our machines are unlikely to go down simultaneously. When web-pool goes down and is restarted, no problem; traefik will find it in the cluster and resume routing connections normally.
If our ingress-pool went down, the situation would be more severe, since we need our external IP bound to that machine. How else would our clients land on our web backend? Remember we don't have an external load balancer...

Luckily, we have kubeip which will detect the recently rebooted ingress-pool machine and assign our external IP back to it in no time. Crisis averted!

There's a couple key things in our traefik deployment that sets it apart from our other deployments. First is hostNetwork which we need for traefik to listen on network interfaces of its host machine.
Secondly, we define a toleration, because we have tainted the host node pool. Since our traefik deployment is the only one with this toleration, we can rest assured that no other application is deployed on ingress-pool.

Finally, we give traefik some arguments : entry points for HTTP, HTTPS and health check (ping in traefik lingo). We also enable the kubernetes provider, which lets us use custom resources. Let's create them now:

kubectl create --save-config -f resource.yaml

Now we can add routes to traefik using our new custom resources:

kubectl create --save-config -f route.yaml

The two routes now connect the "web" and "websecure" entrypoints (which we set up as arguments for traefik) to our nginx-web service. We should now be able to see HTML content served to us by nginx when we connect to our static IP address.

Please enjoy your cluster-on-a-budget responsively!

Creating an FFI-compatible C-ABI library in Rust

Otto Rask — Fri, 31 Jan 2020 09:15:19 +0000

This is part 2 in our PHP FFI + Rust blog series. Previously we took a look at how the FFI feature can be enabled and used in PHP 7.4, and now we will jump over to Rust and see how we can create C-ABI libraries ourselves, which can then be loaded using PHP FFI.

Why Rust?

C would be the obvious first choice when writing C-ABI libraries, yes. But alas, I am more versed in Rust than in C. I know how Rust works in general and what features are available, but am not an expert by any means, while I only know how to compile a C program and that's about it.

When using Rust there are some extra steps needed when compiling C-ABI compatible libraries, namely making sure our compiled code and logic is aligned and packed according to the C standard and creating a header file which C-ABI consumers can use to locate our code which they want to run.

Requirements

We will be working with stable Rust and a single external crate in this post. I assume you have Rust and Cargo installed and are ready to compile Rust programs from the command line. I am working on Linux Ubuntu, but the steps should be similar for other environments as well.

Example code

All code introduced in the series is available at GitHub in the examples repository I have created. Check the 201-rusty-hello-world directory, which contains a runnable example for the code we're about to write here in this post. You can edit and tinker with the code on your own machine and see what happens.

rask / php-ffi-examples

Runnable examples to learn how PHP FFI works

Rust Hello World

First we want to make a regular non-C-ABIfied Rust library just to have a starting point for this post. We will take this starting library and convert it to a C-ABI dynamic library in later steps.

Let's initialize a new blank library:

$ cargo init --lib my-library

With the skeleton in place, we can check it works by running cargo test which should return a passed test for the dummy test we have been scaffolded in src/lib.rs:

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Now we can go in and write a Hello World library for the greater good! Open the project in an editor of your choice, and let's begin by altering the unit test inside lib.rs. We want to have a function that returns the string Hello world! to whomever calls it.

Our test could look like:

#[cfg(test)]
mod tests {
    #[test]
    fn test_library_function_returns_correct_string() {
        let result = get_hello_world();

        assert!(result == String::from("Hello world!"));
    }
}

We call a function and expect it to return "Hello world!". Simple stuff so far. Let's run the test:

$ cargo test
error[E0425]: cannot find function `get_hello_world` in this scope
 --> src/lib.rs:5:22
  |
5 |         let result = get_hello_world();
  |                      ^^^^^^^^^^^^^^^ not found in this scope

error: aborting due to previous error

Oh no! Our function is nowhere to be found! Let's fix that. In the lib.rs file, create a new function to fix our error:

/// Return a hello world string to the caller.
fn get_hello_world() {}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_library_function_returns_correct_string() {
        let result = get_hello_world();

        assert!(result == String::from("Hello world!"));
    }
}

We created a new function, and also added use super::*; to the tests module definition to load it into the test scope. Now if we attempt to run tests, we are greeted with a compilation error instead of a test failure:

error[E0308]: mismatched types
  --> src/lib.rs:11:27
   |
11 |         assert!(result == String::from("Hello world!"));
   |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected (), found struct `std::string::String`
   |
   = note: expected type `()`
              found type `std::string::String`

Now the compiler knew the function was available, but type checking failed as we are not returning a String from the get_hello_world() function. Let's fix that:

fn get_hello_world() -> String {
    return String::new();
}

Let's test again:

running 1 test
test tests::test_library_function_returns_correct_string ... FAILED

failures:

---- tests::test_library_function_returns_correct_string stdout ----
thread 'tests::test_library_function_returns_correct_string' panicked at 'assertion failed: result == String::from("Hello world!")', src/lib.rs:13:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.


failures:
    tests::test_library_function_returns_correct_string

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

We did not get compilation errors, which is great, and now our actual testcase failed. We can see that a string was returned (because it compiled) but the strings do not match. To see what the comparison contains, we can convert to assert_eq!():

#[test]
fn test_library_function_returns_correct_string() {
    let result = get_hello_world();

    assert_eq!(result, String::from("Hello world!"));
}

And now when we run cargo test we get a better understanding what we are exactly comparing:

running 1 test
test tests::test_library_function_returns_correct_string ... FAILED

failures:

---- tests::test_library_function_returns_correct_string stdout ----
thread 'tests::test_library_function_returns_correct_string' panicked at 'assertion failed: `(left == right)`
  left: `""`,
 right: `"Hello world!"`', src/lib.rs:13:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.


failures:
    tests::test_library_function_returns_correct_string

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

Pay attention to the lines starting with left and right. We see the right side is the expected value from our test, and the left side does not match. We now need to fix our code to make them match:

fn get_hello_world() -> String {
    return String::from("Hello world!");
}

Now our tests should pass gloriously:

running 1 test
test tests::test_library_function_returns_correct_string ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests example-01-hello-world-library

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Woot!

We now have a library we could package up and ship to crates.io for others to use! But let's not do that, as we have other plans. Time to make it C-ABI compatible!

Writing C-compatible Rust

Writing C-compatible Rust might sound scary, complicated, and strange, but it really is not too difficult. Rust and C share quite a bit in the ABI-compatibility department, meaning in general Rust can be compiled as a C library assuming you're not doing anything strange.

The biggest pain point is converting between C and Rust data types and memory guarantees.

Assuming our library function in Rust returns a String, which is an entirely Rust concept, we cannot use that directly in C. What we can do, is juggle with a raw pointer (gasp!) and convert the data held by our String into a C-friendlier format.

Let's introduce two new functions which become our public API over C-ABI. Add the following functions and tests for them in the lib.rs file:

use std::os::raw::c_char;
use std::ffi::CString;

fn get_hello_world() -> String {
    return String::from("Hello world!");
}

#[no_mangle]
pub extern "C" fn c_hello_world() -> *mut c_char {
    let rust_string: String = get_hello_world();

    // Convert the String into a CString
    let c_string: CString = CString::new(rust_string).expect("Could not convert to CString");

    // Instead of returning the CString, we return a pointer for it.
    return c_string.into_raw();
}

#[no_mangle]
pub extern "C" fn c_hello_world_free(ptr: *mut c_char) {
    unsafe {
        if ptr.is_null() {
            // No data there, already freed probably.
            return;
        }

        // Here we reclaim ownership of the data the pointer points to, to free the memory properly.
        CString::from_raw(ptr);
    }
}

#[cfg(test)]
mod tests {
    use std::os::raw::c_char;
    use super::*;

    #[test]
    fn test_library_function_returns_correct_string() {
        let result = get_hello_world();

        assert_eq!(result, String::from("Hello world!"));
    }

    #[test]
    fn test_library_cabi_function_works() {
        let ptr: *mut c_char = c_hello_world();
        let cstring;

        unsafe {
            cstring = CString::from_raw(ptr);
        }

        assert_eq!(CString::new("Hello world!").unwrap(), cstring);
    }
}

The good old get_hello_world() function has been left as is, but we've introduced a new function that calls it: c_hello_world(). We also have a secondary function c_hello_world_free(ptr: *mut c_char), which is used to free the memory that the first function has reserved. We will take a look at it later.

c_hello_world() looks like a regular Rust function, but with some sprinkling on top:

#[no_mangle]
extern "C"
-> *mut c_char

The no_mangle attribute instructs the Rust compiler to not alter the function name when it is inserted to a binary file. This makes it easier for FFI users to call it, as the name is kept as "human-readable".

Writing extern "C" defines that this function should be callable outside Rust codebases, and the "C" portion instructs the Rust compiler to optimize the function for usage in C-ABI consumers.

The return type on the other hand is a raw pointer. A mutable one at that. Scared yet? I know I am.

Running cargo test should see the test passes for this new function as well. In the test function we call the C-compatible function, and assert that it produces a pointer to a string that is stored in C format (CString).

Raw pointers as explained by a Rust newbie

Rust has two of these raw pointer thingies: *const T and *mut T, where T is the type of data the pointer points to in memory. The *const and *mut parts seem like they are some dereferencing operator thingies, but they are not. They are literal type declarations for raw pointers. I was confused as well.

It is relatively rare to need to use these types of pointers when you're working on a pure Rust code base. They offer some powers that regular Rust does not provide, and are also required when interfacing with other languages, such as C.

What raw pointers essentially allow us to do is move stuff between the Rust world and C world using them. Well not move the stuff itself, but more like give an adress from Rust to C and vice versa: "The thing you want is here at this address, but I am not helping you with how to use it or process it". Yay pointers!

The data raw pointers point at can be anything. It could be *const String, or maybe *mut MyStruct. The type declaration just lets Rust know what it might be working with.

Working with raw pointers is unsafe in Rust, meaning you need to know what you're doing with them. For simple things you can get away with one or two unsafe blocks, but for complex stuff, you must pay attention. Otherwise you're corrupting or leaking information in memory.

Passing the pointers themselves around is not unsafe, but the second you want to read, modify, or delete the data they point to, you are in unsafe territory.

You also need to make sure the data behind raw pointers is freed properly. In Rust terms, when we create a raw pointer, we lose ownership and lifetime guarantees to a degree.

In our code we use CString::into_raw() and CString::from_raw() to momentarily release Rust ownership to C land, and then take it back. The from_raw() also triggers lifetime checks, and frees the data/memory using Rust rules. If you do not do this, you will most probably leak memory in you programs.

You should also check if you're working with a null pointer before doing anything with the data the pointer may or may not point to.

What about the `*_free` function?

We added two functions for our C-ABI compatible API. One creates a CString, and the other is supposed to free memory which was created for the CString. How does this work and why is it done this way?

In C, you are in charge of memory. This means you are responsible for allocating memory, and freeing memory. Rust itself has guarantees in place that allow you to skip the low-level stuff most of the time, but in C you need to be more careful.

With our C-ABI we are allocating memory inside Rust, and then passing that memory pointer to someone outside Rust. This creates a situation where we "disable" the Rust borrow checker and lifetime rules for that allocation. Someone outside Rust can erase the memory, alter it, and so on.

With the free function, we provide a tool for the external code to return control of memory to Rust, after which Rust is again in charge with borrow checks and other guarantees.

In terms of FFI, we first call c_hello_world() which allocates memory inside Rust and provides us with a pointer to the allocation (T::into_raw()). After we're done using the memory, we call c_hello_world_free() with the same pointer which we received earlier, and then inside Rust we "consume" (T::from_raw()) that pointer to return control back to Rust.

A similar pattern is already in use inside PHP. fopen() and fclose() follows the same semantics for example. You open a resource, do work with it, and then you close it to prevent mistakes from happening, even if that would just mean a memory leak or similar.

Compiling into a C library

When we compile our example library right now, we only get a Rust library out of it (.rlib), which is quite useless if we want to use the library in a C-ABI FFI setup.

To alter what is compiled and where, we need to alter our Cargo.toml configuration.

If you have not touched it since we initialized the project, it should look something like this:

[package]
name = "my-library"
version = "0.1.0"
authors = ["John Doe <johndoe@example.com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

Quite bare, and a good starting point.

To change our compilation from a Rust library to a dynamic C library, we need to introduce a [lib] definition:

...

[dependencies]

[lib]
name = "my_library"
crate-type = ["cdylib"]

After that is in there, running cargo build should result in a libmy_library.so library appearing inside target/debug.

Hey, now we could take that file and use it in PHP! Does the following look familiar?

<?php

$ffi = \FFI::cdef(
    'ok this is missing for now',
    'libmy_library.so'
);

Neat stuff. The only thing we now need is a header. Let's create a new file into the target/debug directory (for now, later we will move those things elsewhere) called my_library.h:

#define FFI_LIB "libmy_library.so"

char *const c_hello_world();
void c_hello_world_free(char *const str);

Now we have

libmy_library.so
my_library.h.

We can use those in PHP as follows:

<?php declare(strict_types = 1);

$header = file_get_contents('/path/to/library.h');

$ffi = \FFI::cdef(
    $header,
    '/path/to/libmy_library.so'
);

$cstr = $ffi->c_hello_world();
$phpstr = \FFI::string($cstr);
$ffi->c_hello_world_free($cstr);

echo $phpstr;

Running that should output Hello world! in your terminal. How cool! Notice we first called the string (read: pointer) returning function, and after we read the contents to a PHP string, we call the memory freeing function to make sure we are not creating leaks.

Next up: how to automate writing these C header files, instead of manually tinkering with them every time our C-ABI API changes in Rust.

Automating C headers generation with `cbindgen`

In the Rust ecosystem, there are a multitude of libraries and tools with bindgen in their names. cbindgen, wasm-bindgen, etc. The naming comes from "bindings generator", and they are used to assist in creating cross language and cross binary bindings. With cbindgen we can create bindings (headers) from Rust in a C-ABI compatible way.

Using cbindgen for really small projects might be overkill, but I would say it is not a big dependency to depend on maintenance-wise.

To get cbindgen we need to modify our Cargo.toml:

...

[dependencies]

[build-dependencies]
cbindgen = "0.9.*"

...

We added a new section, called build-dependencies. This means Cargo will install those to be used in a crate build process, not the crate contents itself. cbindgen is used during the build process, so we install it this way.

Now you can run cargo update and it will fetch and install the dependency.

Once installed, we need to create a build step. Cargo supports a thing called build scripts, which are bare Rust files that are invoked when building a crate. Create a build.rs file next to Cargo.toml, and insert the following contents:

extern crate cbindgen;

use std::env;
use cbindgen::Language;

fn main() {
    let crate_dir = env::var("CARGO_MANIFEST_DIR").unwrap();

    cbindgen::Builder::new()
        .with_crate(crate_dir)
        .with_language(Language::C)
        .generate()
        .expect("Unable to generate bindings")
        .write_to_file("target/debug/my_library.h");
}

It is short, and the only thing we do is instantiate a cbindgen builder instance, alter the configuration a bit, then generate and write the headers to a wanted location on the filesystem.

To make Cargo use this build file, we need to add it to the Cargo.toml file:

[package]
name = "my-library"
version = "0.1.0"
authors = ["John Doe <johndoe@example.com>"]
edition = "2018"
build = "build.rs"

...

Notice the build key containing the build.rs file path.

When we now run cargo build, hopefully we see some header generation magic happen.

(Note: I had to run build twice, as somehow the cbindgen crate had to be compiled in two runs, try it if nothing appears that looks like a header file.)

Once compilation is done, check the target/debug directory. Can you see the my_library.h file? Check the contents. It should show a header similar to the one we manually wrote earlier, but now it has some new stuff. This means the cbindgen build worked, and now we have automated the generation of header files for our C-ABI library.

What cbindgen does, is it parses our source code for definitions that are marked as extern "C" or similar, and generates the bindings automatically based on those.

We would like to have cbindgen automatically insert the FFI_LIB definition into the header as well, in order to be able to use the \FFI::load() method instead of the \FFI::cdef() method in our PHP code. Also there are some unwanted includes in the header which are not needed with PHP FFI as far as I know.

cbindgen currently has no configurability for creating constants like FFI_LIB, but we can hack those in using the cbindgen::Builder::with_header() method. Add the following changes to build.rs:

cbindgen::Builder::new()
    .with_crate(crate_dir)
    .with_language(Language::C)
    .with_no_includes() // First we strip the default include lines which are not needed
    .with_header("#define FFI_LIB \"libmy_library.so\"") // then we insert our custom definitions, the .so path is relative to the header file we're writing
    .generate()
    .expect("Unable to generate bindings")
    .write_to_file("target/debug/my_library.h");

A bit hacky, yes, but works. Now if you run cargo build, the header should contain a new line which defines the FFI_LIB constant, and the default includes should be gone. Now we have a header file which is compatible with \FFI::load() in PHP land.

What's next?

Okay, so now we know how to write basic C-ABI and FFI-ready libraries in Rust, and also took a super quick peek at how to use those in PHP via FFI. Additionally we looked at how to use cbindgen to do some tedious work for us automatically.

Homework: try and see if you can work out how to add a user-supplied parameter to the get_hello_world and c_hello_world functions, so they can return Hello World, <param>! or similar.

In the upcoming posts in this series we will be writing some more complicated code, meaning we need to learn a bit about the various types that are available in PHP FFI from the C-ABI, and how to write Rust code that operates on those types as well.

Introduction to PHP FFI

Otto Rask — Mon, 18 Nov 2019 14:59:11 +0000

In this series of posts, we will be getting acquainted with a new PHP feature: FFI!

In addition to getting to know PHP FFI, we will be learning how to create and use FFI libraries written in Rust.

FFI is a new addition to PHP starting from version 7.4. In a nutshell, it allows you to run external binary code via a wrapper written in PHP. The binary code can be anything which supports the C-ABI.

Disclaimer: I am not a C/Rust/ABI/FFI expert, I am writing this series to learn things as a PHP developer as well. If you see errors or other things that should be changed, please do let me know.

FFI? ABI?

FFI (Foreign Function Interface) is a way for two separate codebases to integrate via an ABI (Application Binary Interface). One of the most common ABIs for FFI usage is the C-ABI, which defines the binary calling conventions and data structures for compiled C programs. The C-ABI convention is supported by various other non-C languages a well, such as Rust.

In essence you can load and call code from a C library inside PHP, or any other language that supports FFI via C-ABI.

Why would I want to use FFI?

FFI is great if you need to run resource intensive code and your "own" programming language is not up to the task (e.g. extensive parsing, number crunching, complex rendering, etc.). Instead of using two entirely different programs to do a single thing in steps, you can "glue" two codebases together inside a single program to do the single thing more efficiently. Or maybe you have a good C-ABI library readily available, and just want to save time by not rewriting it in PHP for instance.

FFI can provide performance boosts, but sometimes it might actually make your programs slower. We will be looking at some simple benchmarks on what works well and what does not at some point. Tricky business, but hopefully we can find the good spots where FFI will be of help. If not, we will see good and bad use-cases in the future when more PHP folks start using FFI.

Python has become one of the most popular languages for machine learning and number crunching partly because of FFI. It is relatively simple to load and use powerful C-ABI libraries in Python (via FFI), which in itself is a relatively easy language to learn.

What to expect from this blog series

This series will walk us through the following in some way or another:

Introduction FFI in PHP (this post),
Creating FFI-libraries for PHP in the Rust programming language,
How to use C types in PHP,
Benchmarking a few FFI use-cases, to see when FFI is the more performant choice and vice versa,
Creating sane and testable FFI abstractions in PHP,
How to properly integrate FFI with the PHP preloading feature,
Creating distributable PHP Composer packages that make use of FFI,
Ensuring safety when writing and using FFI libraries in PHP.

I mainly use Linux Ubuntu when programming, so you may have to alter the steps I describe throughout this series to make things work right in other environments. Occasionally I might show a cross-platform way to do things, but do not rely on those working as I have no other systems to test things out on at the moment.

I am writing this series mainly for two reasons:

It gives me a good excuse to learn more about PHP, FFI, Rust, and C,
It gives me a good excuse to teach somebody something useful, as I like to do when blogging.

So hopefully I will learn new stuff and you will learn at least a thing or two as well in the process.

Let's go!

Example source code

To support the blog series, I have created a code repository that contains example code. The examples are runnable, meaning you can see what happens when you run them and change things.

The example code is available at github.com/rask/php-ffi-examples. You can download/clone the repository to your machine to run and modify as you wish. If you see errors there, you can create issues or send pull requests.

rask / php-ffi-examples

Runnable examples to learn how PHP FFI works

To run the PHP examples, you need a FFI-compatible PHP interpreter build, which we'll take a look at next.

Installing and configuring FFI for PHP

PHP 7.4 ships with FFI built in. It is a core extension, meaning it can be disabled. PHP can also be compiled without the FFI extension.

At the time of writing, PHP 7.4 is still under unstable version development. This means we do not have any official stable builds available for PHP FFI coding.

If you do not have a FFI-enabled PHP build available, you may have to compile a compatible binary of PHP yourself. NOTE: Some popular package repositories provide unstable PHP 7.4 builds that have FFI enabled.

There are tons of guides online for compiling PHP from sources in various ways, but if you're somewhat familiar with the process or compiling C programs in general, you can follow the steps outlined below:

$ sudo apt-get install build-essential autoconf automake libtool bison re2c
$ git clone https://github.com/php/php-src
$ cd php-src
$ git checkout php-7.4.0beta4
$ ./buildconf
$ ./configure --prefix=/home/<user>/php/7.4.0beta4 --with-ffi --with-zlib
$ make
$ make test
$ make install

We pass in --with-zlib to be able to use some compressed data such as compressed PHARs while working. You may need a dependency for it. With --prefix we set where the installation process puts the compiled binaries and other required data.

After these steps (if successful) you will have a PHP CLI binary sitting in /home/<user>/php/7.4.0beta4/bin/php. You can check that FFI is available by running

$ /home/<user>/php/7.4.0beta4/bin/php -m | grep FFI

If the FFI module is not loaded, verify your build configuration, build steps, and the generated php.ini file (found inside /home/<user>/php/7.4.0beta4/lib or a similar location).

I recommend adding the built PHP binary to your $PATH, as we will be using it on the command line quite a bit over the course of this series.

Configuring PHP FFI

By default FFI is enabled only in the following cases:

You're running PHP using the CLI SAPI (i.e. you're running PHP scripts in your terminal or via cron or similar use-cases)
You're using the new PHP 7.4 preloading feature when running a web application

If you want to disable FFI, you need to alter your php.ini. Look for a line similar to

ffi.enable=preload

And set the value from preload to false. If the line is prefixed with a ; comment marker, remove the marker as well.

If you want to have FFI enabled at all times instead, you can set the value to true. This means FFI is available outside preload and CLI. You might really want to reconsider using this setting in production environments, as it will most probably make your application slower and less safe. For web application development environments it might be a good choice, as you do not need to rely on the preload mechanism when working on your code, and implement the preloading mechanism later on.

Now that we have PHP with FFI available, we can start coding.

FFI Hello World

Example code provided in 101-hello-world directory of the examples repository.

What would a tutorial or series be without a Hello World example? Behold:

<?php declare(strict_types = 1);

$ffi = \FFI::cdef(
    'void printf(char *const str, ...);',
    'libc.so.6'
);

$ffi->printf('Hello %s!', 'world');

If you run it, it should print Hello world! into your terminal window, as expected from a hello world program.

Now let's go through it piece by piece.

<?php declare(strict_types = 1);

// Here we begin creating a new FFI definition.
//
// `cdef` is used to first input C headers, then provide the location of a C-ABI
// library that provides the implementation for the header.
$ffi = \FFI::cdef(

    // Here we provide the C header. It can be a string, which is loaded
    // from an actual file as well using `file_get_contents()` or similar.
    //
    // In this example we define the `printf` function that accepts a regular
    // string. Note the `...`, which is for C variadics.
    'void printf(char *const str, ...);',

    // Next we point to the C-ABI library file that hosts the
    // implementation itself.
    //
    // In this example we load the global system `libc.so` library, meaning the C
    // standard library. This may or may not exist depending on your setup,
    // meaning you need to validate which library file to load.
    //
    // The "6" at the end is part of the filename, and carries no special meaning
    // in terms of loading a library.
    'libc.so.6'
);

// Lastly, we make use of the generated FFI definition. We have the
// functions defined in the C header available to be used through
// the FFI object.
$ffi->printf('Hello %s!', 'world');

So far so good. We now know how to load a C-ABI library and call its functions from PHP. And it is not really that verbose either! If you want a PHP analogy, it looks a little like we're using a factory method to instantiate a class filled with magic methods that have been defined elsewhere.

Alternate method for loading

Example code provided in 102-hello-world-with-load directory of the examples repository.

You can use the cdef method for loading a library, but you may also use the load method, which loads and parses a single C header file and infers the library to load from it.

Given you have a C header file called header.h written as such:

#define FFI_LIB "libc.so.6"

void printf(char *const str, ...);

The FFI_LIB definition is used to set the path to a dynamic library that should be loaded for this header file.

Otherwise it can be a somewhat regular C header file.

You can replace the cdef in the hello world example above with:

<?php declare(strict_types = 1);

$ffi = \FFI::load(__DIR__ . '/header.h');

$ffi->printf('Hello %s!', 'world');

This makes the loading a little simpler, and you get some separation of concerns when it comes to defining what libraries you intend to use, and what functions and other goodies you want to use from those libraries.

Scoped method for loading

There is a third method for loading a C library, using a feature called FFI scopes.

Scopes are available only when you are using the PHP 7.4 preloading functionality. The following example is really simple and unrunnable, and you will need to setup your preloading configuration and scripts properly if you intend to use scopes.

Given you have a header.h file as such:

#define FFI_SCOPE "helloworld"
#define FFI_LIB "libc.so.6"

void printf(char *const str, ...);

You can then use something like the following in your preloading script:

<?php declare(strict_types = 1);

\FFI::load(__DIR__ . '/header.h');

function my_printf(string $text, string ...$subs) : void
{
    static $ffi;

    if (!$ffi instanceof \FFI) {
        // This string argument is the same as the
        // `FFI_SCOPE` definition in the `header.h` file
        $ffi = \FFI::scope('helloworld');
    }

    $ffi->printf($text, ...$subs);
}

And then in your "nonpreloading" normal code you could call FFI as such:

<?php declare(strict_types = 1);

my_printf('Hello %s!', 'world');

This is of course a very bare example, and you also need the preloading configuration and boilerplate in place to make use of scopes properly. Scoped loading is preferred when preloading, as it provides some performance improvements over the cdef and load methods.

FFI errors

The FFI feature throws errors in a few situations:

Invalid library header or binary definition for cdef and friends,
Runtime errors when accessing FFI state or resources.

For example, if your C header is malformed, you will be greeted with an error:

<?php declare(strict_types = 1);

$ffi = \FFI::cdef(
    'hello this is invalid',
    'libc.so.6'
);

This will throw an \FFI\ParserException which lets you know that your header is not valid.

When accessing resources that do not exist (e.g. are not available in the loaded C-ABI library), you might receive something like follows:

<?php declare(strict_types = 1);

$ffi = \FFI::cdef(
    'void idonotexist();',
    'libc.so.6'
);

// PHP Fatal error:  Uncaught FFI\Exception: Failed resolving C function 'idonotexist'

If you attempt to call a C-ABI function that does not exist, you receive the following:

<?php declare(strict_types = 1);

$ffi = \FFI::cdef(
    'void printf(char *const str, ...);',
    'libc.so.6'
);

// Above is fine and works, but now we attempt to call something that is not available:

$ffi->some_function();

// Uncaught FFI\Exception: Attempt to call undefined C function 'some_function'

If you try loading a C-ABI library that does not exist, another exception is thrown:

<?php declare(strict_types = 1);

$ffi = \FFI::cdef(
    'void printf(char *const str, ...);',
    'idonotexist.so'
);

// Uncaught FFI\Exception: Failed loading 'idonotexist.so'

Handling errors

Example code provided in 103-hello-world-with-trycatch directory of the examples repository.

All FFI errors are either instances of \FFI\Exception, or descendants of it. So the simplest approach to making your FFI loading a little less fragile is to use a generic try-catch as follows:

<?php declare(strict_types = 1);

try {
    $ffi = \FFI::load(__DIR__ . '/header.h');
} catch (\FFI\Exception $e) {
    // log error, do fail tasks, prevent running, etc.
}

$ffi->printf('Hello %s!', 'world');

This is a simple example. We have not taken care of the following situation for instance:

<?php declare(strict_types = 1);

try {
    $ffi = \FFI::load(__DIR__ . '/header.h');
} catch (\FFI\Exception $e) {
    // log error, do fail tasks, prevent running, etc.
}

$ffi->function_which_is_not_defined(); // oops

Handling raw FFI exceptions is not the best solution, and you will most probably want to abstract your FFI interactions behind a class or similar, which provides saner error handling itself.

Another option could be to run some up-front tests against the FFI instance during loading or in automated tests to make sure the library works. This might not work well enough in the end though.

In any case these are outside the scope of this introductory post, and we will look at FFI abstractions in a later installment of this series.

Wrapping up

In this part we took a look at the requirements for FFI installation and configuration, and also learned a few ways to load and use a C library inside PHP using FFI.

In the next part, we're going to learn how to write a C-ABI library using Rust, and hopefully learn a bit about how the C-ABI works and how Rust libraries should be constructed to be a little more FFI-friendly.

Are legacy browsers worth supporting?

Lassi Heikkinen — Tue, 22 Oct 2019 08:15:06 +0000

TL;DR

Yes, if your potential users use them.

Introduction

In June 2019 verkkokauppa.com was visited or tried to be visited by 34 different browser vendors, by 1518 browser versions, by 20 operating systems and by 4271 screen dimensions. That's a lot to support especially when considering the number of possible combinations.

A fundamental problem in web development since the early days has been drawing the line which browsers and devices to support and which not. Ultimately the question is how to keep the website serving as many users as possible while making use of the helpful features of the modern browsers which the vast majority of users use anyway.

When tackling the problem two questions are asked: if non-standard code (aka browser hacks) are justified and how small ROI (Return of Investment) is justified in order to support a broader set of browsers. In other words the second question is: how much time can be invested to support more browsers.

Perhaps we should also take a closer look if the browsers are used to generate any revenue or are some browsers used more like for fun.

Let's look at one approach how to determinate which browsers are worth supporting.

Tools

First we want to gather all data available to make as good decisions as possible. Our tools and sources include:

Google Analytics 360 (GA) to know how the users behave.
Browserslist (BL) to see what browsers our potential users use.
Can I use (CIU) to see what technologies different browsers support.
CrossBrowserTesting (CBT) to test how our website behaves in different browsers.
BrowserHacks (BH) to find technical solutions to specific browser errors.

Results

While the actual data is business critical and classified we can share a few interesting highlights from June 2019. We use revenue weighted data ourselves but that cannot be shared.

Operating systems by visits

OS                   Share
--------------------------
Android            38.79 %
Windows            29.56 %
iOS                24.70 %
Macintosh           5.66 %
Linux               0.98 %
Chrome OS           0.20 %
Windows Phone       0.06 %
Playstation 4       0.01 %
Tizen               0.01 %
Xbox                0.00 %

Source: GA

Other operating systems include: Xbox, Blackberry, OS/2, FreeBSD, Nintendo WiiU, NetBSD, OpenBSD, Nintendo 3DS, Playstation Vita and SunOS.

Screen dimensions by visits

Dimensions           Share
--------------------------
 360 x 640         13.01 %
1920 x 1080        11.09 %
 375 x 667          9.36 %
 768 x 1024         4.74 %
1366 x 768          3.84 %
1536 x 864          3.48 %
 375 x 812          3.17 %
 360 x 740          3.06 %
 360 x 720          2.64 %
 320 x 568          2.63 %

Source: GA

Browser vendors by visits

Browser                  Share
------------------------------
Chrome                 53.02 %
Safari                 24.62 %
Firefox                 7.47 %
Samsung Internet        3.93 %
Android Webview         3.60 %
Edge                    2.38 %
Internet Explorer       2.21 %
Safari (in-app)         1.62 %
Opera                   1.00 %
YaBrowser               0.09 %

Source: GA

Browser versions by visits

Browser                Version       Share
------------------------------------------
Chrome                    74       27.93 %
Chrome                    75       20.86 %
Safari                    12       20.05 %
Firefox                   67        5.39 %
Samsung Internet           9        2.94 %
Chrome                    73        2.18 %
Internet Explorer         11        1.99 %
Android Webview           74        1.82 %
Safari (in-app)        (n/a)        1.46 %
Edge                      17        1.21 %
Safari                    11        1.21 %
Chrome                    72        1.16 %
Android Webview           75        1.04 %

Source: GA

According to this data 9.15 % of our website users use mobile in-app browsers (Samsung Internet, Android Webview and Safari in-app) which is surprisingly high number.

Browser versions used by at least 1 % of Finnish internet users

Browser                Version       Share
------------------------------------------
Chrome                    74        36.3 %
Chrome                    73        16.5 %
Safari                    12        16.7 %
Firefox                   66         4.9 %
Chrome                    71         2.4 %
Internet Explorer         11         1.8 %
Chrome                    72         1.6 %
Samsung Internet           8         1.5 %
Chrome                    57         1.4 %
Edge                      17         1.4 %
Safari                    11         1.2 %
Chrome                    70         1.0 %
Samsung Internet           9         1.0 %

Source: BL

On average our website users seem to use more modern browsers than Finnish internet users in general.

Discussion

Looks like the in-app browsers are gaining popularity. They should be investigated in a more detailed manner.

But the question of this study, what browsers to support? Should we focus on browsers that are used most today or browsers that have more potential?

The easy answer is that let's support all browsers. The better browser supported website in technical terms, the more revenue, right? Unfortunately in business we don't have time to support browsers that do not generate revenue. But first we must know the reason why a browser isn't generating revenue. Either users just don't want to use that particular browser to purchase or our website isn't working on that browser. If the latter is the case, we might want to fix it - or not.

To make the decision we can't look at our own data because it doesn't reveal the browsers which don't work with our website. Luckily we have market data from BL to tell the browser shares of Finnish internet users, our primary customer base.

To use BL data we must decide first how many different browsers we have the resources to test often enough to be able to keep the promise of supporting it. In our case a realistic set could include 10-20 browsers but how to select those browsers to have as broad coverage as possible?

After making a few iterations it looks like that by supporting 11 browser versions we can attain over 93 % coverage if we assume that when a website works in a specific version (like Chrome 49) it works in all newer versions too (eg. Chrome 57, 59 etc).

Here are the commands and data to find out the numbers:

$ ./node_modules/browserslist/cli.js "> 0.1% in FI"
and_chr 74
and_ff 66
android 4.4.3-4.4.4
android 4.2-4.3
chrome 73
chrome 72
chrome 71
chrome 70
chrome 64
chrome 63
chrome 59
chrome 57
chrome 49
edge 18
edge 17
firefox 66
firefox 65
firefox 60
firefox 52
ie 11
ios_saf 12.2
ios_saf 12.0-12.1
ios_saf 11.3-11.4
ios_saf 11.0-11.2
ios_saf 10.3
ios_saf 10.0-10.2
ios_saf 9.3
ios_saf 8
op_mini all
opera 58
safari 12.1
safari 12
safari 11.1
safari 10.1
samsung 9.2
samsung 8.2
samsung 7.2-7.4
samsung 4

$ ./node_modules/browserslist/cli.js --coverage=FI "> 0.1%"
These browsers account for 93.66% of all users in the FI

Then we combine the versions to minimize the number of tests needed:

Browser             Version
---------------------------
Android Chrome           74
Android Firefox          66
Android WebView         4.2
Chrome                   49
Edge                     17
Firefox                  52
Internet Explorer        11
iOS Safari                8
Opera                    58
Safari                 10.1
Samsung Internet          4

After combining the versions we have a set of 11 browser versions to cover 93.66 % of Finnish internet users (2019-07-02). The coverage is actually a bit higher because there are also some newer but less popular versions of for example Chrome which were left out of data because of the 0.1 % threshold.

Conclusion

One takeaway of this study is quite many users use mobile in-app browsers. Those browsers are difficult to test and support but they could probably generate more revenue if they were looked more carefully.

The introduced approach to select browsers worth supporting is a so-called quantitative model based on hard data. But in real life the result should be adjusted by the knowledge of experienced developers who may have a good grasp what are the estimated efforts of supporting different browsers. For example supporting Samsung Internet 4 might require too much effort compared to its 0.23 % share.

To sum up: use data but use it wisely.

Afterword

If the browsers could be tested automatically, the set could be much broader and the coverage could get closer to 100 %. CBT has an API but it lacks some browsers and it's not trivial to automate purchasing tests.

Another takeaway here is that we could monitor GA data to see if generated revenue by some browser version suddenly drops to zero in one day. The reason could be a regression bug that has affected the specific browser to make it not work on that website anymore. Depending on the amount of the revenue loss, the bug is fixed.

The last point is a little bit out of scope of this study but the anti-pattern from the '00 that tells users the website is best viewed in browser X, had a good point that no-one is going to switch their browser because of some website tells so, even if it's Verkkokauppa.com. But on the other hand if no-one tells the user about it, how can he know that his browser is out-of-date? It's like a closed door in a physical store not telling when it will be open. The relevant information should be offered for the customer but let himself to decide what to do.

Development work at Verkkokauppa.com

Lassi Heikkinen — Tue, 27 Aug 2019 05:56:00 +0000

TL;DR

We use React, Node, PHP, MariaDB and ~101 other open-source technologies in a big company. We are very pro and hip.

Foreword

Verkkokauppa.com is the largest online retailer in Finland, turnover being roughly 500 million. We have developed our systems in-house and used open-source software since the company was founded in 1992. The strategy to have internal software development teams has been one of the key decisions to land where we are today, building one of the best ecommerce websites in the market.

But we are not just professional and proud of our work, we are also super trendy. We even started to blog what we do and how we do in order to give something back to the dev community. Being transparent is also an evil attempt to lure you to join us. (fluency in Finnish is a requirement)

This article discusses briefly how our development work is done and what our technological choices are today. Focus is on the customer facing website.

Organization

Roughly half of our sixty employees in the tech department are working with internal systems such as product management, storage, logistics, point-of-sale machines and other physical world problems. About a fourth of people are in supportive teams and roles such as infra, testing, planning, DevOps, SecOps and DBAs. And then there are two web teams dedicated to the website the customers face and use. One web team is focusing on the platform (APIs, integrations, build tools etc.) and the other team is looking after the user experience (design, usability, accessibility etc.)

Process

We manage working by using agile model based on Scrum since 2013. Two weeks sprints are in use and we have dedicated Scrum Masters, Product Owners and a coach. Planning, Grooming, Cross-Team Planning, Retrospective, Review, Demo and Daily, we have it all! We have also opportunity to play and find new things every second sprint in Proto Friday.

From the developer's point of view it takes about 4-5 hours per week to participate all scrum meetings. Because heavy processes will always become overhead for the actual work, we try to keep the meetings as compact and relevant as possible. The same ideology goes with project management where Trello has been our choice since 2014.

We use git, GitLab and A Sane git Workflow to control our codebase state. Code reviewing is encouraged.

Technologies

Finally here's a list of the most essential technological choices of our site that make it possible to deliver a great customer experience for thousands of simultaneous online users.

Platform

Kubernetes
Docker

Persistent data

MariaDB
MongoDB

Non-persistent data

Redis
LocalStorage

Back-end

PHP: Symfony, Composer
Node: Hapi, NPM
Webpack, Babel, code splitting
PHPUnit, Robot, jest

Front-end

React: Redux, universal rendering
HTML: schema.org
CSS: Sass

Future

We are quite happy with our choices at the moment. Today radars are reporting on Styled Components, Preact, Svelte, GraphQL, WebAssembly but our focus at the moment is on refactoring codebase to use the technologies listed above and making new features for the users. Plus keeping the business people happy–you never know what they figure out next week.

Forem: Verkko­kauppa.com

How to: Kubernetes for Cheap on Google Cloud

Kubernetes

Aggressive optimizations

Deployments

nginx-web

kubeIP

traefik

Creating an FFI-compatible C-ABI library in Rust

Why Rust?

Requirements

Example code

rask / php-ffi-examples

Runnable examples to learn how PHP FFI works

Rust Hello World

Writing C-compatible Rust

Raw pointers as explained by a Rust newbie

What about the *_free function?

Compiling into a C library

Automating C headers generation with cbindgen

What's next?

Introduction to PHP FFI

FFI? ABI?

Why would I want to use FFI?

What to expect from this blog series

Example source code

rask / php-ffi-examples

Runnable examples to learn how PHP FFI works

Installing and configuring FFI for PHP

Configuring PHP FFI

FFI Hello World

Alternate method for loading

Scoped method for loading

FFI errors

Handling errors

Wrapping up

Are legacy browsers worth supporting?

TL;DR

Introduction

Tools

Results

Operating systems by visits

Screen dimensions by visits

Browser vendors by visits

Browser versions by visits

Browser versions used by at least 1 % of Finnish internet users

Discussion

Conclusion

Afterword

Development work at Verkkokauppa.com

TL;DR

Foreword

Organization

Process

Technologies

Platform

Persistent data

Non-persistent data

Back-end

Front-end

Future

Forem: Verkkokauppa.com

What about the `*_free` function?

Automating C headers generation with `cbindgen`