anynines is going live – best time to give it a go!

anynines goes out of betaThis is an article about anynines – from the very beginning to the final going out of beta.
If you want to learn about anynines history, keep on reading – if you’re eager to know what will happen in the future, hop to the last paragraph of this post!

Why we founded anynines

anynines was founded in April 2013 at the Avarteq Headquarters in Saarbrücken, Germany.
From the beginning hosting was an essential part of Avarteq and we gained first-hand experience in this field with Enterprise-Rails, a hosting brand featured by Avarteq.

With that knowledge, it became clear to us that we want to take hosting to a next, revolutionary level – establishing an European Platform as a Service (PaaS) based on the Open Source software Cloud Foundry.

We gathered in a first brainstorming session to find a name for our new product. We always push hard for 99,999…% availability and application security in hosting, so we decided on the name anynines shortly before our brains set on fire. We never thought we’d spend so much time on a brand name alone!

anynines was born and we set out into the future of Cloud-Hosting. We started, naturally, with a beta.

What we did during the beta phase

Firstly, we set up our team. In the first days our team had a size of three to five people but over the months more and more new members joined the team. The team members these days were Julian Fischer, the founder of anynines and one of the CEOs of Avarteq, Oliver & Julian for the development part, Nico for admin tasks and me for the marketing.

For final copywriting and design we worked together with Mirek Woźniak and Mariusz Cieśla who both did a fantastic job and we could welcome Floor Drees who was responsible for the growing community. 

Why did we choose Cloud Foundry?

We compared different emerging PaaS projects to have an overview over the market and believed in the concepts of Cloud Foundry. We believe in the power of Open Source standards which also enforced our decision towards Cloud Foundry as a basis for anynines.

Our estimation proved to be correct and Cloud Foundry has developed to the market leader in Open Source Platform as a Service frameworks with a rapidly growing community and the well funded Cloud Foundry Foundation behind the project. To manage our infrastructure automation we used BOSH from the beginning. In our vision anynines should support both – private and public usage scenarios.


Hence Cloud Foundry was our first choice for establishing anynines. There were some obstacles to overcome.

We had to stabilize the runtime and weigh out Cloud Foundry components equally. We also had to implement an invoicing integration, a customer panel and fill other feature gaps.

Service development

Because the existing community services unfortunately were outdated and not high available as we needed them to be. For our vision of anynines we have to create highly available updated service solutions on our own. These will be available soon.

Establishing the anynines community

We had the PaaS and the IaaS but as we all know – an awesome idea is nothing without people learning about it and joining the movement. So we had to establish social media channels, a support board, marketing strategies and and and…

A big issue for us was to get in touch with the people we want to provide anynines to as an alternative European service to PaaS providers from the US. So we started sponsoring meetups, workshops and conferences and visiting them.
So our anynines community began to grow and today a solid group of anynines enthusiasts is helping us by giving important feedback, writing tutorials and HowTos and even mentioning us in blog articles.

Out of Beta our biggest challenges

So here we are now – going out of beta and providing a functional European Platform as a Service solution for application developers. In addition we work hard with our partners to support them in creating their own private PaaS solutions based on the anynines software stack.
But before this day we had some big challenges to cope with. For example we switched from a rented VMWare infrastructure layer to a self hosted OpenStack IaaS layer.

What the “out of beta” means to you

If you’re already an anynines user you’ll automatically enter a 30 day trial period for your application instances with the same quota as during the beta phase. The only thing you have to do – if you didn’t already – is to deposit your payment data. This is important because after these 30 days the resources you use with your account will be charged for. In case you want to view a list of used resources in detail – just have a look at the customer panel.

That brings the future

We are focused on bringing new features regularly to you. To give you a short view about what we’re working on we’ll go deeper into the anynines service development plan. Our goal is to exchange each community service one after another. We’re also working on service instance connections via client tools from outside of the cloud.

Right now we are testing our MongoDB service implementation internally which includes high available Replica Sets, the latest MongoDB version and dedicated service instances.
In addition we are preparing internal PostgreSQL test runs for our new service implementation which provides a high available cluster solution, the latest PostgreSQL version and dedicated service instances.

We also work on developing a Redis service. Not to forget the Diego (next generation application executor) integration we want to provide to you as soon as possible.

As you can see there is a lot going on so you can be curious what we’ll bring to you in the future. If you have not worked with anynines yet – just try it out.

How to deploy on anynines using Typesafe Activator


A short version for the impatient.

I assume you’ve got git, Typesafe Activator and an anynines user account.
Clone the source:

$ git clone

Skip to “Push it to the cloud” below.

Typesafe Activator is cool and here’s why

I know Java since the mid-nineties and to be honest it’s my favorite weapon of choice when it comes to coding.

I’ve done much web development in the past and when I heard about Play! Framework many years ago I was pretty excited. Take the philosophy of Ruby on Rails adopt it to Java and you’ve got Play. Play evolved over the years and is now wrapped inside Typesafe Activator. In fact, I stumbled upon Activator because of Play. Activator can do way more than I use it for but it lets me get things done quickly.

Lately I got to know about anynines and one of the first things I wanted to do was to deploy a Java application to anynines. Nothing fancy, it wasn’t even a web app – just a kind of “Hello World” app, but it serves well to show how to combine Activator and anynines.


To follow my steps you’ll need a working JDK on your machine as well as Typesafe Activator, the cf CLI and a anynines user account.

Creating the basis

Let’s start with setting up a fresh Activator project first:

$ activator new

Fetching the latest list of templates...

Browse the list of templates:
Choose from these featured templates or enter a template name:
1) minimal-akka-java-seed
2) minimal-akka-scala-seed
3) minimal-java
4) minimal-scala
5) play-java
6) play-scala
(hit tab to see a list of all templates)
> 1
Enter a name for your application (just press enter for 'minimal-akka-java-seed')
> a9s-java-pingpong
OK, application "a9s-java-pingpong" is being created using the "minimal-akka-java-seed" template.

Now cd in the freshly created directory and run:

$ activator

You’re now inside the Activator shell where you may issue commands.

Modifying the application setup

I usually use Eclipse to do Java coding, however there is an Eclipse Plugin for SBT that we can use to have SBT (yes, we are in Scala-land by now :) generate Eclipse project files from our Activator project.

Additionally, we’ll need a plugin for SBT that allows us to package our final app in a way that is suitable for the cf CLI in order to deploy our app to anynines. To accomplish that task we’ll use the SBT Native Packager plugin.

Modify “project/plugins.sbt” (create the file if it doesn’t exist) as follows:

addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.0.0")

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "3.0.0")

Append the following lines to “build.sbt”:

lazy val root = (project in file(".")).enablePlugins(JavaAppPackaging)

EclipseKeys.withBundledScalaContainers := false

Restart Activator (STRG+C) for the changes to take effect.

Modifying the code

Fire up your favorite code editor or let SBT generate Eclipse project files while you make yourself coffee. From within Activator run:

> eclipse

Now you may use Eclipse’s “import existing project” function.

We want our Actors to constantly play Ping-Pong, so we’ll remove the counter in PingActor and modify the onReceive method as follows:

public void onReceive(Object message) throws Exception {
  if (message instanceof Initialize) {"In PingActor - starting ping-pong");
    pongActor.tell(new PingMessage("ping"), getSelf());
  } else if (message instanceof PongActor.PongMessage) {
    PongActor.PongMessage pong =
      (PongActor.PongMessage) message;"In PingActor - received message: {}",

    // schedule ping to be send in 1 second
      .scheduleOnce(Duration.create(1, SECONDS),
        new PingMessage("ping"),
  } else {

Now modify the onReceive method of PongActor as follows:

public void onReceive(Object message) throws Exception {
  if (message instanceof PingActor.PingMessage) {
    PingActor.PingMessage ping = (PingActor.PingMessage) message;"In PongActor - received message: {}",

    // schedule pong to be send in 1 second
      .scheduleOnce(Duration.create(1, SECONDS),
        new PongMessage("pong"),
  } else {

Feel free to test the app locally by executing

> run

inside Activator.

It’s alive! Push it to the cloud

Since we have a working application now, let’s run it in the cloud. We’ll use the SBT Native Packager plugin to have everything we need packed for a successful deploy. Open Activator and run:

> universal:packageBin

Relative to the root directory of the project we get a ZIPped archive:


Make sure that the target for the cf CLI is correct:

$ cf api

Then login using your credentials selecting ORGs and spaces as you like:

$ cf login

Now let’s push our application to anynines:

$ cf push pingpong --no-route \
  -b \
  -p target/universal/

Since we do not provide a HTTP interface (remember: our application does not interact with the outside world), we tell cf with the no-route option to avoid route creation (and with that the corresponding health check).

Voila! Let’s check if our application is running:

$ cf app pingpong
Showing health and status for app pingpong in org ***_*** / space test as ***@***...

requested state: started
instances: 1/1
usage: 256M x 1 instances
package uploaded: Mon May 4 13:57:33 +0000 2015

       state   since                    cpu    memory           disk        details
#0   running   2015-05-04 03:58:13 PM   1.4%   148.5M of 256M   125.3M of 1G

Looks good! Now watch the Actors play Ping-Pong:

$ cf logs pingpong

Well done!

You’ve just successfully deployed a plain Java application (using main(.) as PEP) to anynines. Plus, we’ve used Akka to have two Actors play Ping-Pong.

With that knowledge we are ready to start building asynchronous messaging applications that are heavily scalable using Java, Akka and anynines. But that’s for the next episode – as for now, stay tuned to our twitter and shoot me an email if you’d like to talk about Scala-land :)

Anynines service framework – A Platform for data holding systems

As you probably know, anynines is build on top of Cloud Foundry which lets you easily deploy and scale applications in a just few minutes. There is a restriction, though: to profit from Cloud Foundry functionality, your application should be build on a shared nothing architecture which means it should be stateless.

Imagine one of the simplest applications – a blog. Even a new comment made by a visitor changes the state of the application. It’s obvious that even a simple application has to store state (data). To handle this we use the so-called “backing service” systems – databases like MySQL or MongoDB fall into this category. And there are many more: Redis, RabbitMQ, Neo4j, CouchDB, elasticsearch, Riak, Cassandra, and so on. It seems that a new awesome database service rises every day!

Why you’ll like our framework

We select and show only the most vital features to give you the best user experience in managing service instances. Our engineering team does some automation to handle the specifics of each service and all you need to do is to choose a service from the anynines catalog and create an instance with just a single command:

cf create-service a9s-mongodb Venus-HA-20

The “`cf create service“` command lets you select a service plan specifying the topology, isolation and capacity of your service instance. Here are some possible plans with MongoDB as an example:

  • Service instance with x MB storage on a shared replica set
  • Service instance with x MB storage on a dedicated node (no replica setup)
  • Service instance with x MB storage on a dedicated replica set
  • Service instance with x MB storage on a dedicated shared replica sets

Not only the creation of the service must be automated, but also there are other important features to cover:

  • Updating service plans on existing instances to increase capacity, isolation or availability. This should be done with the minimal possible downtime and zero downtime if possible.
  • Upgrading services themselves. From MongoDB 2.6.6 to 2.6.7, for example. No downtime here if possible as well.
  • Automatic detection and recovery of failing nodes.
  • Users should be able to allow and disallow connection from the Internet to perform data changes by hand or make manual backups.

And that’s basically how we take care of However…
We’ve got some additional challenges prepared for those who think that a service integration like this isn’t that complicated. We’ve got some additional challenges prepared for you. Read on!

 Challenge one – Rapid service integration!

Since there are so many different services and the needs of our users are constantly changing, we need a framework that’ll allows us to quickly integrate new services.
Ideally a system that describes the topology of each service plan in a declarative way. Do Amazon Cloud Formation or OpenStack Heat solve this problem? Or do they generate even more problems? Let us know! And have a look at challenge two below.

Challenge two – Infrastructure independent provisioning!

Besides our public PaaS offering we are helping companies set up private clouds on their existing infrastructure. We use our service framework for this, of course, hence this requires the framework to perform integrations on AWS, OpenStack, vCloud, etc. With this requirement in mind, BOSH seems to be the technology we have to use as one component in this framework.

BOSH is a deployment automation tool. The ability to deploy distributed systems to different infrastructures is there by design. Moreover, BOSH allows you to describe the topology of your distributed system in a simple yaml file and it takes care of the monitoring and recreates failing nodes. In case your system is out of resources, you are also able to scale it horizontally as well as vertically in just a few simple steps.

Do you think that BOSH is the right weapon of choice? Or are we wrong? We’d love to hear from you – just tweet us or shoot us an e-mail!