Tag Archives: collab

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!

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!