Azure Functions proxy - overview

Azure Functions are great for building a bigger solution, which contains smaller services representing logical separation of different responsibilities. There's however a problem if you'd like to encapsulate logic what can be accessed and which HTTP methods are allowed. Additional problem arises if you're going to somehow avoid passing function keys to each application consuming or using your function. Fortunately Microsoft has just published a public preview of Azure Functions proxy - a very simple yet powerful concept, which allows you to overcome mentioned problems and make your functions to even more fun to work with.

Special thanks to @marekgrabarz for making me aware of this feature and encouraging to write some words about it.

Hide your functions

Actually to take advantage of this feature there's one requirement - a Function app. If you don't have one, quickly go to Azure Portal and create one!

Once you have your Function app created, simply click on it. You will see a Function app screen with a new feature added:

as you can see it's still in preview so it may be still a bit unstable, but it won't bother us in this moment. To be actually able to use proxies, you have to enable them. Go to the Function app settings and turn proxies on in the Proxies(preview) section. Now we can do some real work!

Create a simple function, for which we'll create a proxy. For the testing scenario I created a following function:

/
using System.Net;

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{    
    return req.CreateResponse(HttpStatusCode.OK, "You called ProxiedFunction1!");
}

now with a function created, we can create a proxy for it. To do so, follow below steps:

  1. Click on the New proxy button
  2. Give it an unique name and template(I used proxy/function1)
  3. For Backend URL you have to use any URL you'd like to forward a request to(in my case it was my function Function URL with the key)
  4. Simply click a Create button

Now try to access your proxy by going to https://{your_function_app).azurewebsites.net/{template} - if you used the same function as me, you'll get "You called ProxiedFunction1!" as a response. You can create as many proxies as you want and connect them to the resource of your choice(it can be a function, a web app or other endpoint accessible with HTTP). Your possibilities are unlimited here.

Parameters and application settings

You can also create a proxy in more generic way simply using parameter in your route. Consider following example:

Whatever you pass as a {function} parameter, it will be routed to the ProxiedFunction1 function

Additionally you can reference application settings what can be helpful if you're searching for more flexibility. Let's create another proxy like this:

What is more, I added MY_SECRET key with a value of a5gYhj87Hgsta to the app settings. How when I try to access proxy, I can go to https://my-app.azurewebsites.net/proxy/secret/a5gYhj87Hgsta and get desired results. If a secret doesn't match, you'll get HTTP 404 instead.

Alternatives

Currently alternative to this kind of proxy is using Application Gateway or API Management. The advantage of this solution is its simplicity and cost related - since Azure Functions are free for the first 1M requests*, it's possible that in the beginning you will be running this solution for free.

Summary

Currently proxies for Azure Functions are limited in functionality by the preview version. Fortunately the team responsible for this component promised many enhancements implemented soon - can't wait to test them :)

* considering duplicated request when a proxy rewrites it, depending on how proxy is treated in pricing, it can be lowered to 0.5M free requests

EventStore on Azure and Ubuntu - it's a piece of cake! #1

EventStore is a well known, open-sourced and a solid database designed to be the very foundations of event-driven systems. What is great about it is the fact, that it can be built against both Windows and Ubuntu systems, what widens technology stack it can be used with. If you prefer Linux solutions and would like to build an event sourced solution based on ES, there's nothing that will stop you. In this short series of posts I will present how to quickly install, configure and manage EventStore using Ubuntu VMs from Azure.

Getting VM

You can obtain Ubuntu 14.04 VM from the marketplace in Azure Portal. There's nothing special about its configuration or size - for the purpose of testing it can be whichever you like and you're comfortable with. Once you fill in all fields and provision the whole environment, we can connect to the machine and try to install the database.

Installation

To connect to the VM you need an SSH client and credentials you provided during VM installation process. I personally recommend using PuTTY in Windows environment since it's lightweight and completely free. Once you're logged in, we can start installing EventStore instance.

Firstly run following command:

/
curl -s https://packagecloud.io/install/repositories/EventStore/EventStore-OSS/script.deb.sh | sudo bash

Once you have EventStore preconfigured, you can install it:

/
sudo apt-get install eventstore-oss=3.9.3

You can choose any version you like, in this particular post I selected 3.9.3 since it was the most recent one available.

Once EventStore is installed we can run it using this command:

/
sudo service eventstore start

and use curl to sent testing event to make sure everything is all right. To make things easier, take following JSON from the documentation:

/
[
  {
    "eventId": "fbf4a1a1-b4a3-4dfe-a01f-ec52c34e16e4",
    "eventType": "event-type",
    "data": {
      "a": "1"
    }
  }
]

and use following command to send an event:

/
vi event.txt
curl -i -d @event.txt "http://127.0.0.1:2113/streams/newstream" -H "Content-Type:application/vnd.eventstore.events+json"

Note that we're using vi to quickly create events.txt file using JSON from above. When you execute the command, you should receive HTTP 201 Created response:

/
HTTP/1.1 201 Created
Access-Control-Allow-Methods: POST, DELETE, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-Forwarded-Host, X-PINGOTHER, Authorization, ES-LongPoll, ES-ExpectedVersion, ES-EventId, ES-EventType, ES-RequiresMaster, ES-HardDelete, ES-ResolveLinkTo
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ES-Position, ES-CurrentVersion
Location: http://127.0.0.1:2113/streams/newstream/0
Server: Mono-HTTPAPI/1.0
Date: Wed, 22 Feb 2017 08:09:26 GMT
Content-Type: text/plain
Content-Length: 0
Keep-Alive: timeout=15,max=100

Note that the configuration file used by EventStore is located in /etc/eventstore/eventstore.conf and since it's read-only, you will have to use sudo command to change something in it. For now, leave it as it is.

What's next?

In the next posts I will present how to access EventStore from your local computer and what to change to be able to send and receive messages from it. We'll end this series running a simple cluster of EventStore instances on 3 different Ubuntu machines.