a9s 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!

Table of Contents

• Why you’ll like our framework
  • Challenge one – Rapid service integration!
  • Challenge two – Infrastructure independent provisioning!

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!