Tag Archives: collaboration

Cutting-Edge Cloud Trends

8After receiving an invitation to be a guest speaker at Intel Capital Technology Day in The Hague, Holland, I was honored to share how ElasticBox can help the most complex enterprises. This event was a gathering of the most renowned companies in the IT & Telecommunications sector such as Gya, Aternity, Avegant, Identec Solutions and more.
Read More

Building a knowledge tree of deployment automation

Communication Exchange

Think of a repository where you are able to consume knowledge that someone shared as well as understand how it works. Does GitHub come to mind? What if you could do the same thing with deployment automation? ElasticBox boxes are your GitHub equivalent for sharing, running, and explaining deployment automation code. Read More

60 best open source tools to do DevOps


Don’t you love free stuff? When it comes to automation, open source tools are coveted because they attract support from the developer community. So we compiled a list of the best. Take a look. Read More

The last one that transformed the future

Happy DevOps

The headline made her yelp for joy. A year into the future of D-Chip, on a crisp August morning, Phoebe opened the newspaper and swiped to the technology section on her iPad. What she saw was riveting: D-Chip reborn as a star in wearable computing. Read More

Three-in-one benefits of LDAP integration


LDAP Groups is a new feature soon coming to ElasticBox. It helps sync LDAP groups in your organization with ElasticBox workspaces. A team of users in your org can now sign in with their org credentials and right away start working in a team assigned workspace in ElasticBox. Read More

Making DevOps Culture a Reality

Bringing applications to life is an iterative and collaborative process, whether the application is developed by a single developer in the global community or a large team inside an organization.

It all starts with an idea. Perhaps a small change in an existing application or perhaps a completely new approach towards solving a problem. For most developers, deployment and operations are an obstacle, making it harder or even impossible to implement their ideas. For operations it is also a challenge, the faster the innovation the harder it is to provide a stable environment.

ElasticBox introduced its collaboration features to support this process. Our first iteration focused on open collaboration: it enabled anyone with direct access to a Box to make changes to it and made it easy for developers and operations to build Boxes together and make them available to others, directly or through workspaces.

This first iteration was great for a few people who work together but was difficult to scale. As more people get involved in a project, it becomes more important to control who can do what with Boxes and instances. That is why we are introducing more granular ways to share and define access levels for instances, Boxes, and providers.

Changes to Collaboration Capabilities

We are renaming “Collaboration” to “Sharing” and introducing a new access level. “Collaboration,” as we know it, will now be “Sharing with Edit Permissions.” In addition, we are introducing “Sharing View only.” This will let you share your assets with others without giving them the ability to make changes to those assets.

When you share a Box with Edit Permissions,

  • Recipients will have access to and the ability to edit all versions of the Box
  • Recipients will have access to and the ability to edit the current state of the Box

When you share a Box View only,

  • Recipients will have access to but not the ability to modify all versions of the Box
  • Recipients will not have access to the current state that you’re working on. This is a way to ensure distribution of stable, validated Boxes rather than unstable works in progress.

Sharing instances in View only mode enables some interesting use cases. For instance,  developers can have access to a database in order to bind to their applications for testing, but not make any changes to the database. Sharing instances in Edit mode, on the other hand, is great if you need somebody to help you debug the Box or instance. For more information, please check out the product documentation.

These new features should make it easier for you and your teams to work together in a more efficient way! Another step towards enabling developers and operations to work together and move towards a DevOps culture!

ElasticBox and Infoblox – Say that Five Times Fast!

Hello everyone!

We at ElasticBox are really excited about our partnership with Infoblox to integrate “Network Control” into your process for developing and deploying applications in a cloud environment. To align with the Infoblox press release today, I wanted to provide a little more detail on how Infoblox and ElasticBox work together.

First let’s define the partnership at a high level, and from a conceptual point of view. ElasticBox is a DevOps Platform that enables IT operations to deliver IT as a Service and also provides a collaboration mechanism for operations and developers to define and deploy applications in a modular process across any cloud environment – private, public, and hybrid. Infoblox, on the other hand, provides a powerful solution to centralize and automate network provisioning and control. So together, ElasticBox and Infoblox ensure that when you are developing, orchestrating, and deploying your applications in the cloud, everything – including the network – will work, automatically.

OK, I am being told that I should probably provide some more detail…

ElasticBox uses webhooks to provide a high level of integration to Infoblox. A quick example of how ElasticBox uses webhooks to integrate with Infoblox follows – you’ll see in the diagram below that Infoblox can discover IP endpoints and assign IP addresses reliably in your network.

By using webhooks within ElasticBox, you can integrate that Infoblox network configuration capability into your automated ElasticBox application deployment process. Follow these three steps to set up the integration:

  1. Build a custom web service for Infoblox. On the hosting web server such as Apache, add a web service resource that interfaces with Infoblox. In the resource, add the service, machine, and instance objects that ElasticBox can talk to when making web calls.
  1. Add a customization spec. Add customization specifications for Linux and Windows templates in vSphere so they can accept the custom parameters from ElasticBox.
  1. Add the webhook to ElasticBox. Finally, add the web service host URL as a webhook in ElasticBox.

Once this is done, it’s plug and play. Whenever users deploy applications using Box templates from ElasticBox onto vSphere, ElasticBox sends a HTTP POST request to the Infoblox custom web service. Infoblox returns the machine object appended with the IP address information. ElasticBox passes this on to vSphere to provision the Windows or Linux virtual machine based on the customization spec.

That gives you an idea of how ElasticBox webhooks can integrate closely with your Infoblox solution. Have any questions or need help getting started? Let us know how we can help.

How 1+1+1=5 when Developers, Architects, and IT Ops Truly Collaborate!

When it comes to defining and deploying enterprise cloud applications, traditionally, there has been a healthy tension between the developers, architects, and IT Operations. This is largely due to the needs and success measures for these stakeholders being different and not fully aligned with the overall goals of the enterprise.

Developers want to focus on code and develop, test, and deploy their applications faster with unbridled freedom. Key requirements include:

  • An agile development environment that can be created and torn down at will, on demand.
  • Self-service of infrastructure components, such as servers, and services such as runtimes, databases, load balancers, scripts, etc.
  • Ability to replicate QA, production, or customer environment effortlessly

In general, the QA requirements are similar to those of developers, except with a focus on building a QA setup that is identical to a production environment in terms of scale, performance, security, and other capabilities.

The requirements from architects’ perspective are different but equally important to be addressed.

  • Developing and driving standards and best practices
  • Integrating new technology and rapidly developing blueprint for application innovation
  • Avoiding repetitive, tedious tasks

Meanwhile, the IT Operations team is responsible to fulfill the requests from developers, QA, and architects.

  • Ensuring service level agreements (SLAs) are met for the services consumed
  • Balancing tactical needs with longer term projects
  • Positioning IT as an enabler of innovation and eliminating bureaucracy while retaining control to ensure compliance and governance.

Traditional approaches to addressing these problems have yielded sub-optimal, partial, and siloed  solutions tightly coupled to the underlying cloud infrastructure. Consequently, collaboration is inefficient and lower productivity translates into slower innovation of new applications for the enterprise.

ElasticBox dramatically changes the game by fortifying the synergies between the stakeholders and streamlining the develop-test-deploy cycle in a boundary-less manner. Application definition can be completely separated from the details of the underlying cloud infrastructure.

Using ElasticBox, each of the personas can flexibly integrate their knowledge and expertise into the application life cycle. Reusable software components, called Boxes, can be created which include run times, web servers, and middleware. The library of templates so developed can be shared as a self-service catalog throughout the organization. Access based policies for resource allocation and scaling can be assigned based on users and groups to ensure governance.

This is the power of true win/win/win collaboration between developers, architects, and IT Operations. We simply call it the 1+1+1=5 effect.

What is the level of collaboration in your organization between the developers/QA, architects, and IT Operations? Why not build an application lifecycle process that celebrates the healthy tension between these personas while empowering each stakeholder to unleash their potential?

Self-service and IT governance can harmoniously coexist. Who said you cannot have the cake and eat it too!