Introduction
A week or so ago I read an interesting blog article written by Sravish Sridhar from Kinvey. The core message behind the blog article was that both Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) players are increasingly offering Backend-as-a-Service features but their implementations lack key services which are critical to enterprise mobile charters.
Kinvey entered the BaaS market at about the same time FatFractal did and the features you find in each respective offering are very similar, although I believe FatFractal has a much stronger API and data story, but hey I’m not biased right Image may be NSFW.
Clik here to view.
Both companies started with public offerings and have increasingly transitioned their focus to the enterprise.
While I think Sravish did a great job on his assessment of what BaaS services are needed by the enterprise, I think there is a broader story to be told because in many enterprise engagements the offering needs to be installed behind the firewall (or on a private cloud), IT needs tools to effectively manage, monitor, secure, and scale it, and developers need services to leverage it.
This blog article will focus on the FatFractal Cloud-in-a-Box (CIB) offering which addresses the latter concerns and to a minor extent on the patented FatFractal NoServer offering which is the FatFractal BaaS stack.
How do NoServer and CIB fit together?
I thought it might be useful to quickly provide short descriptions of both NoServer and CIB so that they don’t get all jumbled up and then how they work together.
NoServer is a highly configurable BaaS software stack that is responsible for processing mobile app client REST requests. The NoServer software stack can be configured using a declarative metadata language that is defined with the FatFractal Definition Language (FFDL) file. The FFDL file is very powerful and allows the developer to define collections, impose security and permissions, define custom Javascript server extensions (functionality beyond the basic BaaS CRUD), and much more. If you want to learn more go here.
The CIB is a container (LXC) management platform built on top of docker.io. Each discrete stack, whether it be an API/application (i.e., NoServer, node.js) or service (i.e., MySql, ElasticSearch) stack runs in its own container. The containers, as well as other CIB artifacts (i.e., images, stacks), can be managed through an IT dashboard. The CIB is a tool that allows IT to standardize stack deployment, administration, monitoring, security, and scaling.
So NoServer is a BaaS stack that runs in a CIB container and the combination delivers an enterprise grade mobile platform that provides IT and developers with the tools and services they need to quickly address organizational needs in market time frames.
Why docker.io?
So why did FatFractal select docker.io as the plumbing to its CIB offering? Unlike the FatFractal public footprint up on Amazon, which uses native LXC, the CIB will typically be installed and administered by an IT person into their own environment behind the firewall or onto a private cloud. Docker.io provides both a command-line interface (CLI) and REST API that both provide similar functionality and is facilitated by the docker.io daemon.
The CIB installer creates a collection of containers using the CLI and the IT Dashboard provides container/image administrative functionality by interfacing with the CIB D-OSGi administration services which encapsulate the docker.io REST API. So docker.io provides the CIB with a standardized approach to installing, managing, and scaling its footprint.
In addition docker.io provides the following benefits -
- Isolation of stacks: On a given host/VM you will typically run a myriad of application and service stacks and containers provides an insulated and standardized process for accomplishing this, minimizing potential conflicts.
- Security: Containers allow you to sandbox applications reducing the risk to the whole host/VM.
- Testability and reproducibility: Packaging applications into containers guarantees they will run as tested independent of where they are are deployed.
- Containers: minimizes the pain of say maintaining QA, staging, and production environments across multiple hosts/Vms. In addition when you need to upgrade a component in the container it is fast to run the upgrade, test the resulting container and deploy the diff of the new image to your hosts.
- Limit resource usage: Docker makes it easy to limit the CPU and memory available to an application. This way a rogue process or a traffic spike on your blog won’t necessarily bring down your whole VM.
- Upgrading / downgrading / application versions: Containers makes application management consistent and straightforward simply by maintaining multiple containers.
So while docker.io is not a panecea, it was the best framework for the CIB plumbing.
Why does the enterprise care about CIB?
As mentioned earlier, CIB is built on top of docker.io and provides higher-level functionality such as browser-based administration, monitoring, scaling, application routing, push button application and stack deployment, etc. Docker.io is a fantastic tool but to be leveraged effectively in an enterprise environment it invariably needs to be encapsulated into higher-level tools.
Below are some potential enterprise use cases:
How would IT use CIB.
- IT would use CIB to provide standardized environments for their development, QA, and production teams, thus eliminating the headaches associated with developing in disparate environment (“It works on my machine…”).
- IT would use CIB’s dashboard to administer, monitor, and scale applications through container management.
- IT would use CIB’s private registry to publish images so they can be accessible across the organization.
- IT would use CIB’s dashboard to create pools of containers (virtual clouds) accessible to only those users that have been provided permissions.
- IT would use the standard Dockerfile format and CIB’s dashboard stack management functionality to define and deploy new stacks.
- IT would use CIB to build high availability distributed footprints.
How would developers use CIB?
- Developers can build any app in any language using any stack.
- Developers would use CIB’s console for push button application deployment.
- Developers would use CIB’s console to debug and monitor their applications.
How would the enterprise benefit from CIB/NoServer?
- Turn-key enterprise-grade mobile platform.
- Faster application development.
- A standardized environment for all internal and external development and deployment.
So the CIB is really one of those build or buy it propositions where the enterprises can roll their own docker.io implementations or leverage a platform like the CIB.
What do I get with a CIB?
The CIB consists of several components all of which are deployed as containers that can be distributed across multiple hosts/VMs. These components provide some level of scope as to what is necessary to roll your own docker.io implementation and have a platform similar to that of the CIB.
Image may be NSFW.
Clik here to view.
IT Dashboard
The CIB dashboard provides IT with web based functionality it needs to administrate hosts, pools, services, containers, stacks, and images. IT never has to deal directly with docker.io or infrastructure services, everything necessary can be accomplished through the dashboard.
Image may be NSFW.
Clik here to view.
Configuration
Configuration allows IT to configure the CIB for such things as ActiveDirectory access, infrastructure services access (i.e., AWS, OpenStack, etc.), blob store access (i.e., S3, Swift, etc.) etc. It also allows IT to configure CIB containers (i.e., MySQL, Zookeeper, etc.) which are used by the CIB administrative services.
Hosts
Hosts provides access to compute infrastructure services (if available) for such things as spinning up a new EC2 instance through AWS.
Pools
Pools allows IT to create virtual clouds that consist of containers that can only be accessed by permitted users. An example use case would be development pools for supporting the application life cycle such as test, staging, and production pools. Pools can be quickly cobbled together by assigning containers to them and then giving permission to users or groups of users. An example use case would be that marketing has hired a couple mobile developers to crank out a temporary campaign app which will only be needed for a short period of time. IT can simply create the pool, containers, and then permit those developers access to that pool and delete when it is no longer needed, which releases all resources (i.e. containers).
Services
Services are used to define service dependencies for application stacks. For instance, when the FatFractal NoServer stack was defined it declared it had a dependency on two services; 1) MySQL and 2) ElasticSearch. So when a new container is created with the NoServer stack it must be assigned to a pool that has those services available.
Containers
Containers provides comprehensive management functionality that allows IT to create, monitor, delete, start, stop, inspect, and etc. containers. Typically IT will create a set of containers using a variety of stacks and assign them to a pool.
Stacks
Stacks allows IT and developers to construct whatever kind of application or service stack they wish. Those stacks will subsequently be used to create images. A typical stack will consist of a Dockerfile and associated artifacts (i.e., configuration files).
Images
Images are use to create containers.
Administrative Services
The CIB administrative services are implemented using D-OSGI that are packaged into a container. The CIB administrative services are published to Zookeeper and subsequently discovered and fetched by consumers. The administrative services can be deployed anywhere and multiple containers can be started providing protection against failover.
Image may be NSFW.
Clik here to view.
Infrastructure Services
If infrastructure services are available, the CIB dashboard can be configured to use them and provides access through the Hosts menu selection. Access to all infrastructure services is facilitated through JClouds. The Hosts menu selection provides functionality for starting, stopping, and terminating instances. When an instance is started it is bootstrapped with a node install script that installs such things and the Docker daemon, the CIB agent, etc. The intention is not to replace the things like the AWS console but rather provide convenience functionality for managing hosts where containers will be installed.
Image may be NSFW.
Clik here to view.
CIB Director
The CIB director is responsible for routing and load balancing requests to application containers. When an application is deployed, its container is registered with the director and any subsequent requests are routed to that container. If the application is deployed across multiple containers, the director will load balance requests across the containers.
Image may be NSFW.
Clik here to view.
User Defined Stacks
IT and/or developers can define custom stacks which can then be used to create images and containers. The process for doing so is relatively simple and involves creating a stack build artifact. The stack build artifact is a tar file that contains a Dockerfile and associated artifacts at its root. Once the stack build artifact has been created it can be uploaded through the IT dashboard using the ‘Create Stack’ menu item. Once the stack has been created it is available to create an images and containers.
Below is the Dockerfile used to create the Mysql service stack used by the NoServer stack-
FROM ubuntu:14.04
MAINTAINER Mic Holst <mic@fatfractal.com>
RUN apt-get update -qq
RUN ln -s -f /bin/true /usr/bin/chfn
RUN apt-get install -y –fix-missing mysql-server
ADD my.cnf /etc/mysql/conf.d/my.cnf
RUN chmod 664 /etc/mysql/conf.d/my.cnf
ADD run_mysql /usr/local/bin/run_mysql
RUN chmod +x /usr/local/bin/run_mysql
VOLUME ["/var/lib/mysql"]
EXPOSE 3306
CMD ["/usr/local/bin/run_mysql"]
CIB Developer Console
Image may be NSFW.
Clik here to view.
The CIB developer console provides access to containers in pools the developer has been permitted to access.
The CIB console provides the following functionality -
- Deploy applications.
- Fetch application logs.
- Fetch application analytics.
- Start and stop applications.
- Monitor applications.
Conclusion
So I think Sravish was spot on as it applies to what type of BaaS services the enterprise needs, however, the enterprise also needs a robust and scalable platform off which to serve those services. There are several platform solutions in the market that address the enterprise including but not limited to the CIB, CloudFoundry, Stackato, WSO2, etc. At FatFractal we think we have a winning combination in the NoServer BaaS stack and CIB, everything that is needed to truly build an enterprise grade mobile solution.