Tag Archives: apps

Deploying Apps on Google Compute Engine using ElasticBox – How To Configure Networks, Firewalls and Disks

Part 1 of a two part blog post that shows you how we deploy MongoDB Clusters across different providers. Part 1 will cover Disks, Networks, Firewalls, and Tags. Part 2 will focus on network tunnels, routers and connecting VPCs.

As mentioned in a previous blog post, ElasticBox relies on MongoDB clusters internally for our data needs. In order to create redundancy and high availability for our production MongoDB databases, we deploy them in a VPC on AWS and Private Network on Google Compute Engine across different regions. For anyone who’s had the pleasure of trying to configure such a network, you’ll know that it’s no easy feat.

As we started to work on this scenario, we realized that there were better ways to utilize the available services and configurations from Google Cloud Platform and AWS. So today we’re releasing new features that enable full networking support for Google Compute Engine. Specifically, we’ve made changes to  deployment profiles – our default tool for configuring infrastructure – to make better use of Tags, Firewalls Rules, and Routes. While we were at it, we also introduced the ability to specify disk size.

Here are some the production scenarios we have enabled with this update:

  • Deploying machines with specific sets of rules for security purposes or to restrict public access (public IP address)
  • Using either Tags or Firewalls for configuration purposes to make it easier to choose the right settings
  • Specifying Ephemeral IP or IP forwarding configurations
  • Connecting instances in VPCs or private networks (more coming soon)

To demonstrate the changes we’ve made to our deployment profiles to enable better use of Networks and Disks, we’ll be looking at our MongoDB Replica Box. Which, if you caught our previous post on ‘How To Deploy a MongoDB Cluster,’ you’ll know that the MongoDB Replica Box is a replica instance of the Master MongoDB Box.

Tags and Firewalls:

When deploying an instance of MongoDB on your GCE account, you want to enable certain types of traffic to that instance, and so you might use a specific firewall(s) or tag which you would then associate with that instance when deploying.

When configuring your deployment profile, you can choose which firewall you’d like to use by choosing either the firewall, which will then present the associated Tag, or by choosing the Tag instead. This gives you two options for specifying the network configurations for that instance.

In the case of Tags, we’re using what Google Compute called ‘targetTags’, defined as “A list of instance tags that specify which instances on the network can accept requests from the specified sources. If not specified, this firewall rule applies to all instances on this network.”

For Google Compute Engine, you can now use the ElasticBox Deployment profile to specify disk size. Simply turn on the disks feature in the Deployment Profile and specify the disk size you would like to use. You can also add multiple disks if you like.  As a side note, Google recently announced the general availability of SSD persistent disks for all users and projects.

These upgrades to the ElasticBox deployment profile make it much easier to enable the complex scenarios of managing production instances on multiple providers, configuring networks and connecting VPCs. In the next blog post on this topic, we’ll be covering how to connect the MongoDB Cluster instances we have deployed in VPCs across multiple providers such as Google Cloud Platform, Amazon Web Services, and Microsoft Azure.

Deploying a MongoDB Cluster with ElasticBox

With ElasticBox, you can easily deploy a self replicating MongoDB cluster in just a few minutes. In order to accommodate ElasticBox’s data needs, we rely on MongoDB clusters that run on two public clouds and one private data center.

This way we can provide redundancy, high availability and excellent read and write performance around the world. Using ElasticBox, and our concept of Boxes, which are application or infrastructure components made available as a service, we can consistently deploy a MongoDB cluster in just a matter of minutes on any of our Cloud Providers.

To get started deploying MongoDB clusters on ElasticBox, sign up today for our free account! If you’re interested in other resources on MongoDB, check out how you can easily use Splunk to monitor MongoDB using ElasticBox.

The Basics

What is MongoDB? MongoDB is an open-source document store database.

Why would you want to cluster MongoDB? To provide redundancy and high-availability for production deployments.

How We Use MongoDB

In our case, MongoDB is using a replica set model. A replica set is a group of MongoDB instances that host the same data set. One MongoDB, the primary, receives all write operations. All other instances, secondaries, apply operations from the primary so that they have the same data set.

The primary accepts all write operations from clients. Replica sets can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency.


Deploying MongoDB through ElasticBox

ElasticBox provides a default MongoDB box that’s available to the public. It deploys a standalone instance of the MongoDB server. Our MongoDB production box very closely resembles the default box, minus a few configuration settings required for our production scenario.

While the default MongoDB box configuration is suited for development purposes, it needs to be configured further to use in production. To configure the MongoDB default box for production use, follow the steps below:

Step 1. Create a new box called MongoDB Replica. Add a box variable for the MongoDB Server (this is to use the default box settings).


Step 2. Add a text variable REPLICA_SET to hold the replica set name. This value must be shared between all the members of the cluster.


Step 3. Expand the MongoDB Server box. Edit its file variable COMMON_YAML and paste the following:

mongodb::replica_set: {{ REPLICA_SET }}

mongodb::key_file: /etc/mongod.key



This file will be used by hiera to pass arguments to puppet automatically without modifying the existing puppet default.pp file.

Step 4. Add a binding named primary of type MongoDB Replica (the box you just created).


Step 5. Add an install script. Get the script here.



Step 6. Add a start script. Get the script here.


When you deploy the box without a binding, it creates a cluster for you with an initial configuration. On the other hand, if you bind to an existing instance, it adds the instance to the existing cluster!

There, you have it, a MongoDB cluster in a few easy steps!

Multi-Tier Applications Done Right

One of the biggest problems facing software engineers since the dawn of the multi-tier application is, well, how to make it multi-tier.

It’s more than just having several supporting applications – it is about connecting the layers correctly and allowing them to communicate with each other. All this is to create a scalable and responsive deployment that can be easily updated and adapted to changing business needs.

It is about ensuring that your infrastructure can co-ordinate the order in which your application tiers are spun up, even when the apps themselves have not been designed to perform these critical dependency checks.

What Are You Looking For?

Intelligently handling your solution’s dependencies is an inherent problem in multi-tier deployments – at whatever scale you are operating. For instance,

As a developer working on a project:

“I want to ensure that my database is up and running before my web-server is deployed.”

As the CTO of a rapidly growing startup:

“I want to bootstrap on basic AWS services (such as managed cache, load balancing, and managed databases), but as the product evolves, I want to give myself the freedom to evolve the services I connect to and consume – experiencing as little downtime as possible.”

As the Head of IT Operations of a large-scale enterprise:

“I need to reign in a heterogenous environment where I have hundreds of highly inter-dependent applications that range from just-released to legacy and everything in between.”

At ElasticBox, we’ve found a way to solve this problem using the concept of Boxes, and now, Bindings, a feature we are launching today.


ElasticBox lets you build and deploy complex, multi-tier applications using boxes as basic building blocks. Specifying a ‘binding’ from one box to another is a way to declare that there exists a dependency between the boxes.

It is a construct that allows the different tiers of a multi-tier applications to communicate with each other and exchange data.

Bindings enable users to introduce not just structure, but also flexibility to their multi-tier deployments. For example,

Our developer’s Apache Web-server Box can use a required binding to specify, that to launch correctly it needs a connection to a running MySQL DB instance.

Our startup CTO, who has been trying to make a choice between AWS SQS (Simple Queue Service) and RabbitMQ, can simply switch bindings, with his business application experiencing little to no downtime.

Our Head of IT Operations, can chain his applications so that they come up in the right order. He has the flexibility to modify this chain at anytime – to accommodate new applications or possibly remove old ones, without having to bring the entire system down. If you are thinking about deadlocks – don’t worry, bindings are designed to handle these.

Multi-Tier Applications Done Right_BindingsAsVariablesOn-Prem? Cloud?

For enterprises, bindings can be a very powerful way to evaluate different cloud strategies for business solution with minimal disruption to the existing deployment. Bindings allow switching between an AWS RDS instance and an on-prem database all with a single click.

As you can see from some of the use-cases above, ‘bindings’ is a powerful concept that solves a very prevalent problem in advanced deployments and provides users a simple way to evaluate different strategies. To learn more about how to incorporate bindings into your deployment, please visit our documentation. For a free consultation about how bindings can benefit your particular use-case, please email us at support@elasticbox.com.

Let’s Start with Boxes

What’s a Box? Is it like a container?

I joined ElasticBox in March and this was one of my biggest questions. So what better topic to kick off my blogging career than what a Box is…

Think of a Box as a set of instructions, a DNA, or a blueprint that tells your application components where to go and what to do.

The formal definition: A Box is a reusable, shareable, and portable layer of an application architecture. To create a multi-tier application architecture, you simply stack these Boxes.

Here’s some examples of Boxes and what they do:

  • A Java Box contains the necessary files/scripts to install java onto a generic linux image.
  • A MongoDB Box makes your database portable and modular. You can also add other variables like database permissions to the Box.
  • An NGINX Box allows you to encapsulate your HTTP web server configurations and settings making them reusable for more than one app.
  • A Chef Solo Box deploys Chef Solo on your instance and let you run a Chef cookbook
  • A Git Box allows your instance to have an integration with your source code repository which can be used for continuous integration, for example.

So really a Box can be an OS layer, an app server, a database, a queuing service etc.

We’ve even provided some starter Boxes for you to kick off with. Sign up for our free edition and try them out.

But Why should I Use Boxes?

Great Question!

Boxes are the core building blocks in ElasticBox. The way you define applications in ElasticBox is by “stacking” Boxes, making it an easy and modular process. But the real value of this process is that Boxes are reusable, shareable, and mobile across all major cloud environments.

So what does that really mean for you? It means if you were using ElasticBox and created a Java Box for an app last month, you can just use that Box again for the app you’re working on now. And you can even deploy your current app on a different cloud than the one you used for your last app. If that wasn’t enough, you can even share that Java Box with your colleagues for their apps.

Personally, this is what blows my mind (and I hope yours too)!

Wanna learn more? Email us for a demo.

Hi, My Name is ElasticBox and I am a Cloudaholic

Hello! We, at ElasticBox, feel like we are on a rocketship sometimes but we’re very excited about what we’re doing and want to share all the great news with you. Among other things, we’ve just closed our Series A funding round, re-launched our website, and added several new features to our product that will establish collaboration as the new norm for application development and deployment. Developers, we’re doing this all for you!

So What Does ElasticBox Do Again?

To start, let’s talk about a commonly asked question – just what does ElasticBox do? Well, at the core, ElasticBox is pioneering a new way for developers to create, deploy, and manage applications for cloud environments. The way we look at it, the infrastructure is pretty much solved – but the application is still stuck back in the days of bare metal. It’s time to solve the application! We know this doesn’t tell you the whole story, so come to our website to see why Boxes will be your new best friends. What is a Box, you ask? Like we said, come to our website!

 What Has ElasticBox Been Up To?

  • Funding. Boom. Done: As announced last week, ElasticBox has closed a $9M Series A funding round with Nexus Venture Partners and Intel Capital. This funding will give us the fuel we need to keep adding new features to our product and to ensure as many people as possible can benefit from ElasticBox. Read more about it at this link.

  • A Brand New Website that We’re Dying to Show Off: We are extremely excited to introduce you to our newly-minted website at www.elasticbox.com. We’ve designed this site to clearly communicate what ElasticBox does – and we put a rock on there too. You can also sign up for the free developer edition right on the website.  Wanna know who we are? Check out our lovely pictures.

  • New Features that will Seriously Blow Your Mind: Ok, they won’t really blow your mind, but developers, we’ve got three new features that will make your job a lot easier: Workspaces, Collaboration, and Lifecycle Editor.

    • ElasticBox Workspaces helps enterprises organize teams and development resources for faster app development.

    • ElasticBox Collaboration is a real game-changer that lets you add other developers/workspaces to a Box or application to enable ummm… better collaboration.

    • ElasticBox Lifecycle Editor, a feature unique to ElasticBox, allows you to review, configure, and deploy applications, in real time, all in a single view.

Developers, if you haven’t already, try out these new features by signing up for our free Developer Edition at elasticbox.com/signup and become a Cloudaholic.

Enterprise, want to see how ElasticBox can transform your business to focus on innovation? Request a demo by sending an email to info@elasticbox.com.

Thanks again everyone, and stay tuned for several new exciting features by following this blog for updates at elasticbox.com/blog/

Blog. Boom. Done.

Think Applications, not just Infrastructure

This white paper captures how significant disruptions have created unprecedented opportunities in our journey towards cloud-ready enterprise. From data center automation to virtualization to public clouds to self-service applications, these disruptions were triggered by innovative companies rather than incumbents.

To benefit from these innovations, enterprises need to rethink how they conceive, compose, and deploy cloud applications. ElasticBox, with its application platform as a service, has shifted the frame of reference to applications to transform how you define and deploy applications across any cloud — private, public, or hybrid.

Harness the infinite power of the cloud. Think Applications, not just Infrastructure.

Download the White Paper →

What is an Application?

The other day a colleague and I got into a heated discussion regarding the definition of an enterprise application. He contended that each server hosted 1 or more apps which combined to make an “application stack”. I on the other hand defined an app as all of the components needed to effectively provide a service, regardless of how many servers they were spread across.

It seems like a silly argument I know. You’d be right to say “Who cares as long as it works?” I mean, at the end of the day the only thing that’s important is that the business is getting the service they need right?

Right, and that’s the problem. You see, I realized then that I had the benefit of seeing the world through service assurance tinted lenses. For better or worse I spent 7 years getting more intimate than I wanted to with CMDBs, service models, SLAs, KPIs, etc.. and like the people running the NOC I now viewed the app holistically rather than as a collection of parts. My friend on the other hand hadn’t made this leap and was still thinking in terms of projects, which got me thinking…

Read More