Jamie Perkins

Coming Up In Kubernetes

2016-05-31T00:00:00+01:00

Kubernetes 1.3

If you didn't know, we are currently in the middle of migrating our infrastructure from VMs on AWS to Kubernetes on VMs on AWS. We are holding off for version 1.3 which is due to be released on June 24th. In the meantime we are making all the preparations we can with testing on 1.2, planning our migration and writing all the configuration we can.

I thought I'd write about 2 major additions the new version brings to Kubernetes.

PetSets

Petsets solve a problem with stateful applications and services. You may know in Kubernetes the smallest unit of deployment is a Pod. Pods are ephemeral by design, akin to a running instance of a container image and nuking it when it stops. When the Pod dies, it is permanently gone too, replaced by a new instance with a fresh filesystem, new network identity and all the rest.

This is generally fine except in the cases where an instance of your application wants to survive restarts and stops with it's filesystem and identity intact. For example in the case of a database node.

Petsets solve this problem by giving a unique and stable identity to a Pod. This is important for clustered services that need stable identities to refer to when bootstrapping a cluster or seeding additional nodes. The stable ID allows Pods to retrieve the data (volume) associated with a particular identity, meaning db.node1 still holds the same data between restarts.

Ubernetes (aka Kubernetes Cluster Federation)

This is basically what it says on the tin. Kubernetes as of version 1.2 officially only supports single master, multi slave deployments. This works fine but leaves a single point of failure on the master node, which handles cluster state changes and hosts the Kubernetes API.

Ubernetes aims to place a control plane on top individual Kubernetes clusters to support things like failover between clusters running in different availability zone. Hopefully, in practice this means the automatic and dynamic rescaling of services and applications in response to failure of a cluster and/or availability zone.

Ubernetes actually goes a step further than that. It aims to support the use-case of multiple Kubernetes clusters hosted across different cloud providers (e.g. GCE and AWS) and optionally on-premise bare metal. This is nice, but not something we are likely to use being quite comfortable in Amazon's warm embrace.

One more thing to mention is the changes to the script used to bootstrap a Kubernetes cluster. Titled kube-up.sh, it handles deploying the master and minion nodes, their network configuration and so on. In the case of AWS this means picking the AMI, setting up a VPC, gateways, subnets and more. This is being reworked in v1.3 to support Ubernetes, which should remove the manual work that is needed to setup the same in v1.2.

That's all

Minor disclaimer that anything I've written was parsed from the Github issues and discussions. The general concepts of Petsets and Ubernetes are blockers to the 1.3 release for the Kubernetes team. Their implementation and particular details may vary before release though, so do your own research on if they are right for you.

We're looking forward to lots of things from Kubernetes. Our playing around with v1.2 looked like it could remove a lot of the pain of dealing with heterogenous infrastructure and applications, each configured in different and special ways.

Originally posted on Metabroadcast's blog.

Java Socket Programming With Netty

2016-02-17T00:00:00+00:00

It’s (hopefully) quite infrequent that one needs to work with network sockets directly to chuck bytes around. Normally in an application you’ll use an existing application–level protocol like REST over HTTP to pass data around. The reasons for this include, but are not limited to; convenience, reliability, interoperability and sanity.

That said, should you find yourself in a position where you need better performance or more flexibility than an existing protocol, it’s useful to know where to start.

For example, I used it recently in an IoT project where it would have been time consuming and inefficient to deal with HTTP clients in embedded C++ code.

Netty

Netty is an NIO (non–blocking input/output) client–server framework for Java. It simplifies the process of writing servers and clients that talk to each other under the hood using your typical DatagramSocket, ServerSocket and Socket classes. In this example I’ll show you how to write a very simple server that will accept connections over a TCP port, read and decode JSON and do something with it.

In real life you’re probably more likely to use something binary like Thrift, Protocol Buffers or Smile, instead of JSON.

Getting started

I am assuming you have imported Netty using the dependency manager of your choice and are ready to start typing code.

First off we need instances of NioEventLoopGroup. This class implements a multi-threaded Event Loop, that is, something that constantly and frequently polls IO abstractions for stuff to do like read data or start a new connection. There is also the EpollEventLoopGroup available if you're on Linux, which makes use of the more performant Epoll.

We need two of them, one to accept new connections and one to handle existing connections. If you’ve worked with an HTTP server you’ll know it typically uses the same thing.

Configuring the server

Next we must configure the server proper. Lets walk through.

ServerBootstrap is a helper of sorts that lets you avoid configuring every single aspect of the highly complex ServerChannel implementations. Basically does what it says on the tin, it bootstraps a server for us.

It needs setting up with a few things, first we give it the event loops we created earlier which allows our server to accept and handle connections.

Next is a call to .channel() with a class. Netty will creates instances of this class and uses them to accept new connections. In this case that’s NioServerSocketChannel which is an implementation of ServerChannel.

Then a call to .childHandler() with an instance of ChannelHandler. This is where interesting things will happen, it sets up the pipeline that accepted connections are handled through. Here I’m using a class called MySocketInitialiser, my own creation, we’ll come back to this.

Calls to .option() let us set TCP options on the acceptor. In this case SO_BACKLOG tells the server to refuse connections if it already has 5 queued up.

Finally calls to .childOption() let us set TCP options on the handlers. SO_KEEPALIVE tells clients to keep their connections open with keepalive packets.

We then start the server by telling it to bind to a port at the local address and call .sync() to wait for the server to shutdown.

Setting up a pipeline

Back to MySocketInitialiser to see where the magic happens. The initChannel() method of this class is called by Netty whenever it receives a new connection. A SocketChannel is simply the channel abstraction over a TCP/IP socket.

Each SocketChannel has a pipeline associated with it. You can think of think of the pipeline as an ordered list of handlers with each feeding its output as the input to the next one. There are caveats to this but we can ignore them for now.

In the example pipeline above we have in order the following:

A LineBasedFrameDecoder, this delimits messages by detecting newlines bytes (i.e. \n or \r\n)
A StringDecoder, this decodes bytes into UTF-8 Strings or any other encoding of your choice
A JsonDecoder, this decodes Strings using Gson into objects of type Person or any other type of your choice
An anonymous class that simply prints the name of our decoded Person to standard output

JsonDecoder is not a part of Netty, its implementation is as follows:

That’s everything we need for our example Netty server to do stuff.

Seeing it in action

First we start up the server. How you do this will depend on the way your project is structured:

We can then use telnet to open a socket to our server:

And then in standard out we’ll see:

Wrapping up

There is a huge amount of detail I’ve glossed over for the sake of making this a very easy introduction and to get you off the ground quickly. The Netty user guide goes into more depth and is a good place to start when learning more. If you want to read about NIO in general the Oracle docs are also helpful.

Originally posted on MetaBroadcast's blog.

Spark Framework

2015-12-26T00:00:00+00:00

There's a neat little framework I've used recently called Spark. It is yet another Java HTTP framework, but it's a very small and simple one.

I have written about Dropwizard in the past which is also a small (compared to say, Spring) web framework, but Spark takes it to another level.

Here is a code snippet taken from their site:

That is all (ignoring Maven config) that's needed to start serving HTTP requests from the JVM.

I've not had the opportunity to use Spark in anything resembling a production environment so I cannot vouch for its reliability there. However I have used it for small projects and it's been great doing zero setup before writing code that has an impact on the API's output.

Compare this to the equivalent endpoint using Express:

Uncanny, right? The Java sure as shit wouldn't have looked like that a few years ago...

I know of a few JavaScripters who would like to learn Java but find its learning curve off-putting. Spark may offer a foot in the door by helping to lower that learning curve. It provides a natural application structure far more familiar to those who've used Express in the past than any other framework I've seen so far.

They have easy to follow documentation on both setting up Maven and Spark itself, if you're interested.

Thanks for reading!

Dropwizard

2015-05-28T00:00:00+01:00

As you may know, we have many REST APIs running on the JVM. The majority of which use the Spring MVC framework. We've very much a love/hate relationships with Spring (mostly hate).

An entire series of posts could be written about things we don't like about Spring, but to save time and sanity, I'll summarise as: too much boilerplate and configuration around merely getting the framework to serve HTTP requests. XML config files and ManagerServiceFactoryBeanImplFactory take time to understand and set up, leaving you less time to solve the problem that your application owes its existence to. We use annotations in most places to configure our Spring apps, but it's still a pain to have to deal with in general.

We've now moved two of our projects onto Dropwizard and are so far extremely happy with what we've seen.

What is Dropwizard?

It's a combination of things really as the Getting Started page will tell you. It provides Jetty for HTTP, Jackson for JSON, Jersey for REST and so on. The power and convenience of Dropwizard comes from it's hiding and pre-configuration of the above things right out of the box. To go from nothing to something serving API requests in Dropwizard doesn't require you to write a line of code setting up a Jetty or configuring Jackson.

Everything you need is exposed cleanly, everything you don't is hidden away. This leaves you to start writing code to solve problems almost immediately. The two projects I mentioned above were already using Jetty and Jersey, and so their migrations were fairly trivial. We will be moving Atlas Deer from Spring to Dropwizard sometime in the near future. I'll report back on how that goes and with any useful tips for moving from one to the other.

Example!

The above code, plus a very simple Configuration class and YAML, is all you need to start serving requests from an endpoint in Dropwizard. On top of that there is a long list of built-in, out of the box features that most if not all applications of this type would like.

An admin servlet is automatically configured and started, from which tasks and health checks can be easily built on top of. Other features include but are not limited to:

Logging
Object lifecycle management
Configuration validation
JVM and resource metrics
ASCII art printing at start up

All come for free and only require you to implement the bit you care about.

I'll save going into much more depth for after we've moved a Spring application onto Dropwizard, as I expect there will be far more to show. But so far, we would seriously recommend checking it out!

Originally posted on MetaBroadcast's blog.

Java 8 Method References

2015-03-30T00:00:00+01:00

The following is a fairly reasonable block of code that one might find in a project using Guava.

It's fairly hard to tell just from glancing at this code what it is actually doing. First it's transforming a group of Objects into different Objects, then it's filtering them based on the result of some predicate and then taking the first 5 results. Finally it forces the Iterables.doSomething()s to be evaluated by copying the result into an ImmutableList.

The main problem for this code's readability is those pesky anonymous classes for the Predicate and Function. The problem could be ameliorated by extracting them into constants or, if that's not possible static factory methods. However that is just moving the problem elsewhere. There is one line of code in each of those anonymous classes that we actually care about.

Lambdas and Stream can help things...

So that's turned 10 lines of code into 5. However s -> changeThing(s) this still feels like it could be less verbose, doesn't it? Stream.map() and filter() expects a Function and a Predicate to call respectively, which are both @FunctionalInterfaces and expose a single method. In which case, why are we telling Java how to use something if there is only one way to use it?

Method References

Rather than telling the Stream how to use the method, we simply say there exists a method in this class called changeThing and testThing, go use them.

Some more examples...

This is useful because it means we don't need to create an anonymous class just to invoke an existing method, we can simply reference it to use it as a lambda expression. In cases where you are using an existing project with Guava that has been upgraded to use Java 8 and you don't want to mix Iterables and Stream this lets you take advantage of method references to make the code a little less verbose.

Originally posted on MetaBroadcast's blog.

Hibernate and Postgres FTS

2015-02-04T00:00:00+00:00

Hello! We have a Postgres database that we'd like to search over. After much debate, we decided that Postgres's full text search is good enough. Our initial thought was to use our existing ElasticSearch infrastructure and code — however as we are using Postgres — the built in searching 'comes for free'.

The above article will give you more than enough information to use Postgres FTS, what I wish to demonstrate is getting Hibernate, your friendly neighbourhood ORM, to play nicely with it.

The methodology used here was inspired/learned from this article.

So obviously Hibernate requires you to assert a dialect of SQL that is compatible with the database it must talk to. Here I am declaring it as PgFullTextDialect, this is a custom dialect that I have defined as...

This is where we register additional functions on top of those defined in PostgreSQLDialect, which doesn't contain the full text functions. If you've used PG FTS before, you'll know of ts_rank which is used to get a relevance rank for a search result. You'll also know to_tsquery which turns a string of text (your query) into an object Postgres can use to search.

The one you probably don't recognise is fts, which is infact not a PG function at all but the name I have assigned to the special Postgres syntax of @@, used to compare a text vector to a query vector. Hibernate needs to be made aware of this syntax and requires us to declare a new function type, rather than just the name and return type like we did for the previous two. This is defined as...

Here we have implemented the interface SQLFunction. Like before we declare the return type of the function, we also implement two methods that indicate how Hibernate should handle the method. Crucially however we implement a method that is capable of rendering the function, that is, generating a valid SQL statement given some input. This is where the special syntax @@ is made available to Hibernate.

Finally, using the JPA CriteriaBuilder, we can make an FTS query by asserting that the function fts returns true given a searchString. Note that in this example the field to be search against is hardcoded and therefore is not specified here.

Hopefully this has been helpful if you are using JPA and Hibernate with Postgres for the purposes of full text searching. Thanks for reading!

Originally posted on MetaBroadcast's blog.

Jamie Perkins

Coming Up In Kubernetes

Kubernetes 1.3

PetSets

Ubernetes (aka Kubernetes Cluster Federation)

That's all

Java Socket Programming With Netty

Netty

Getting started

Configuring the server

Setting up a pipeline

Seeing it in action

Wrapping up

Spark Framework

Dropwizard

What is Dropwizard?

Example!

More Postgres - Full Text Search

Materialised Views

Triggers

Java 8 Method References

Method References

Hibernate and Postgres FTS