Archive for the ‘Dojo’ Category

Multi-Cloud MineCraft! Minecraft + Docker + CloudFoundry + vSphere + RackHD + ScaleIO = Awesomeness

Minecraft + Docker + CloudFoundry + vSphere + RackHD + ScaleIO = Awesomeness

Peter Blum

If you didn’t know, VMworld begins next week! Here at the Dojo we thought we would show you a cool project we’ve been working on. MINECRAFT in the cloud!!

With all the clouds out there, both public and private, we wanted to bridge the gap between them. We took a public vSphere cloud and a private bare metal cloud, and layered CloudFoundry ontop. Then with a simple CF push we spin up a Minecraft server from a Docker image. Hmm don’t know if I could put more buzz words into a sentence if I tried…anyhow check it out!

Big shout out to VMWare, RackHD, RexRay, Libstorage, and of course CloudFoundry for helping us make it possible. Also here is a link to our Github (https://github.com/EMC-Dojo/CloudFoundry-MineCraft) where you can find the Docker Image that you can run inside cloudFoundry for your own private Minecraft server.

Cloud Foundry. Open Source. The Way. EMC [⛩] Dojo.

Retrospectives Rock! Our way of ensuring continuous improvement: personally, as a team, and in the industry

Our way of ensuring continuous improvement: personally, as a team, and in the industry

Emily Kaiser

Emily Kaiser

Head of Marketing @DellEMCDojo #CloudFoundry #OpenSource #TheWay #LeanPractices #DevOps #Empathy

There is great philosophical and factual validity behind the concept of empathetic reflection affecting positively people’s lives and interactions with others. Throughout history, people have focused their actions and reactions around this idea both subconsciously and consciously. A famous and often used example of this is the Examen as originally defined by St. Ignatius; the concept of through thoughts, words and deeds, reflecting on where you have been (further what brought you elation, sadness, stress, confusion, etc.), where you are, and aligning these things with where you want to go; continuous improvement of the self.

Here at the EMC Dojo, as our name literally implies, we practice “the way.” A large portion of this form of enlightenment is no doubt found in reflection as practiced through Retrospective, or an exercise our team knows as Retro. The exercise is practiced as explained in the aforementioned example as a form of continuous improvement of our methodology. We use the time to align everyone’s perspective and to ensure we are on the same page in terms of action items and overall goals.

Retro is done every Friday without failure. It is about an hour long and is attended by everyone who plays a role in the Dojo’s operations. Even when members of our Dojo family are working off-site, we ensure that a Google Hangout session is available so that they are virtually in attendance, as this is arguably the most important “meeting” all week. It is the time and space for every employee to speak his/her mind and do so with assumed positive intent, so that feedback can constructively be given and received.

The concept is simple: as a whole team, we are living out the mantra we preach. We are learning by doing; generating weekly action and reaction to our development process through empathetic honesty.    

The person running the exercise for the week (this is not assigned per week, but rather a spur of the moment volunteer) will draw on a white board three columns signified by a smiley face (things that went swimmingly), a neutral face (the so-so items), and a sad face (as your teacher used to proclaim “areas for improvement”). Then all members will add topics/items for discussion from the week to each of these columns as he/she sees fit. These items do not need to be evenly distributed by any stretch of the imagination. That is, no person or team collectively must add the same number of items to the smiley face column as they do to the neutral face column and/or the sad face column (this is part of the honesty piece).

The leader of the exercise will then address each topic/item on the board one item at a time from left to right or right to left (we do this to ensure that we are not making the retro top heavy in any one of the columns). By addressing the topic/item, we mean that the leader will ask the team who wrote the item on the board and why. This is where the importance of this exercise comes to play.

No matter the topic of discussion, in order for the exercise to work and for the team to reap all of its benefits, team members must be completely and empathetically honest about his/her contribution. By doing so, the team learns to navigate conflict by having uncomfortable, but necessary discussions. As with anything, with practice comes perfection. And by perfection, I mean the unattainable kind; something that we are still reaching for 🙂 All kidding aside, it’s true – with every week there are steps back that we learn from paired with giant steps toward our overall goals and methodology.

With the addressing of each topic, the team decides action items that are recorded on the spot. This allows us to ensure that we are offering more than an end of iteration wrap-up, and instead generating real actions and change to ourselves, our team and our organization. We are assessing our ability to break down and solve problems and make improvements –measuring, building and learning constantly in our development process (sound familiar?).

While the exercise was nearly impossible to complete during the birth of our DevOps culture, it is now something that we could not live without. Team issues are no doubt as challenging, if not more, than the technical issues we face. Luckily this exercise allows us to face both and do so with our core value of empathy at its center. We not only are then able to end the week (and iteration) on a high note, but also go into our weekend and following iteration rejuvenated. Retros Rock!

Road trip to Persistence on CloudFoundry Chapter 2

Chapter 2

nguyen thinh

nguyen thinh

nguyen thinh

Latest posts by nguyen thinh (see all)

Road trip to Persistence on CloudFoundry

Chapter 2 – Bosh

Bosh is a deployment tool that can provision VMs on different IAAS such as AWS, OpenStack, vSphere, and even Baremetals. It monitors the VMs’ lives and keeps track of all processes that it deploys to the VMs. In this tutorial, we will focus on how to use bosh with vSphere. However, you can apply the same technique for your IAAS too. The reason we talk about Bosh in this roadtrip is because we use it to deploy Cloud Foundry.


Table of Contents


1. How it works

2. Install Bosh

  1. Create a Bosh Director Manifest
  2. Install
  3. Verify Installation

3. Configure Bosh

  1. Write your Cloud Config
  2. Upload cloud config to bosh director

4. Use Bosh

  1. Create a deployment Manifest
  2. Upload stemcell and redis releases
  3. Set deployment manifest and deploy it
  4. Interact with your new deployed redis server

1. How it works

Let’s say you want to bring up a VM that contains Redis on vSphere, you provide Bosh a vSphere stemcell (Operating System image) and a Redis Bosh Release (Installation scripts). Bosh then does the job for you.

alt text

Are you excited yet? Let’s get started on how to install Bosh on your IAAS and use it.

2. Install Bosh

In order to use Bosh in vSphere, you will need to deploy a Bosh Director VM

1. Create a Bosh Director Manifest

This manifest describes the director VM’s specs. Copy the example manifest from this docs and place it on your machine. Modify the networks section to match that of your vSphere environment.

2. Install

After configuring your deployment manifest, install bosh-init tool from this docs. Then type the following command to deploy a Bosh director VM

3. Verify Installation

After completing the installation, download Bosh client to interact with Bosh director. If you have any installation problem, please refer to: docs

Then type

If the command succeed, you now have a functioning Bosh director.

3. Configure Bosh

To configure Bosh Director, you pass it a configuration file called Bosh Cloud Config. It allows you to define resources, networks, vms type specifically for all of your Bosh vms deployments.

alt text

1. Write your Cloud Config

To write your cloud config, copy the vSphere Cloud Config example here: tutorial and modify it accordingly.

2. Upload cloud config to bosh director

After defining a cloud config, you are then able to deploy VMs on Bosh.

4. Use Bosh

Let’s deploy a simple redis server vm on vSphere using Bosh.

1. Create a deployment Manifest

In this deployment manifest, I am deploying a redis VM using redis release and ubuntu stemcell. I wanted the VM type to be medium and the VM to be located at availability zone z1.

2. Upload stemcell and redis releases

Alternatively, you can download them and run bosh upload locally.

3. Set deployment manifest and deploy it

4. Interact with your new deployed redis server

Find your vm IP using

Connect to your redis server

Test it

One Week at EMC Dojo

Latest posts by Brian Verkley (see all)

I write this while snacking on free banana chips I obtained from the lunchroom. A week in the Dojo is very different than a week programming at home or in a cube farm, and it has as much or more to do with culture than tools and process.

The EMC Dojo in Cambridge, MA (https://www.cloudfoundry.org/welcome-to-the-emc-dojo/) is a place that contributes code to the open source cloud foundry project using a specific development methodology built around pair programming, test driven development, and lean development, known as “the way”. They also teach the way to anyone interested in contributing to Cloud Foundry as well as other development teams within EMC. They earn the title of Dojo by literally being a “place of the way” .

From the moment I got there, I was a member of the team. I had planned to work in the same area, quietly observing the way while working on my own projects. That didn’t work out, and I’m so thankful it didn’t. On the first day, everyone in the Dojo had introduced themselves to me and were interested in what I was working on. They adopted my story into their backlog and encouraged me to attend their standup the next day and begin pair programming with them. I felt so valued before I had even added value. Before long I found myself pair programming on a PHP app (I have no experience in PHP) and doing anything I could to contribute.

They went to lunch together every day I was there, often participating in an office wide Yoga lunch or Go Programming Book Club. They cared about each other’s quality of life and personal hobbies. They struggled out loud with programming syntax and architectural design choices and often came together to discuss, solve, or vote. Every member of the team was heard and had the same weight in decision-making.

And it works. The speed and efficiency that they are able to take a story idea and turn it in to working code is amazing. And although they are all individually quite talented, there seems to be a “greater than the sum of their parts” thing happing with “the way”. They are completed unfazed by tackling something new largely because of their confidence that as a team they will be able to solve it.

What I witnessed, no, what I was a part of for my week, was a team of developers effectively coding for hours based on shared goals and methodology in an environment that made everyone happy. I’m so thankful to everyone who paired with me, shared with me, challenged debated and listened to me, welcomed me, and taught me.

What an outsider might notice first is the ping-pong table next to the cafeteria with available food and no checkout register, but that would be missing the point. The culture that they have built here and the benefits of developing in “the way” have left me with a lot more than this now empty bag of banana chips.

Road trip to Persistence on CloudFoundry Laying the framework with ScaleIO

Laying the framework with ScaleIO

Peter Blum

Over the past few months the Dojo has been working with all the types of storage to enable persistence within CloudFoundry. Across the next few weeks we are going to be road tripping through how we enabled EMC storage on the CloudFoundry platform. For our first leg of the journey, we start laying the framework by building our motorcycle, a ScaleIO cluster, which will carry us through the journey. ScaleIO, a software defined storage service that is both flexible to allow dynamic scaling of storage nodes as well as reliable to enable enterprise level confidence.

What is ScaleIO – SDS, SDC, & MDM!?

ScaleIO as we already pointed out is a software defined block storage. In laymen terms there are two huge benefits I see with using ScaleIO. Firstly, the actual storage backing ScaleIO can be dynamically scaled up and down by adding and removing SDS (ScaleIO Data Storage) server/nodes. Secondly, SDS nodes can run parallel to your applications running on a server, utilizing any additional free storage your applications are not using. These two points allow for a fully automated datacenter and a terrific base to start for block storage in CloudFoundry.

Throughout this article we will use SDS, SDC, and MDM, lets define them for some deeper understanding!
All three of these terms are actually services running on a node. These nodes can either be a Hypervisor (in the case of vSphere), a VM, or a bare metal machine.

SDS – ScaleIO Data Storage

This is the base of ScaleIO. SDS nodes store information locally on storage devices specified by the admin.

SDC – ScaleIO Data Client

If you intend to use a ScaleIO volume, you are required to become an SDC. To become an SDC you are required to install a kernel module (.KO) which is compiled specially for your specific Operating system version. These all can be found on EMC Support. In addition to the KO that gets installed there also will be a handy binary, drv_cfg. We will use this later on but make sure you have it!

MDM – Meta Data Manager

Think of the MDMs as the mothers of your ScaleIO deployment. They are the most important part of your ScaleIO deployment, they allow access to the storage (by means of mapping volumes from SDS’s to SDC’s), and most importantly they keep track of where all the data is living. Without the MDM’s you lose access to your data since “Mom” isn’t there to piece together the blocks you have written! Side Note: make sure you have at least 3 MDM nodes. This is the smallest number allowed since it is required to have 1 MDM each for Master, Slave, and Tiebreaker.

How to Install ScaleIO

The number of different ways to install ScaleIO is unlimited! In the Dojo we used two separate ways, each with their ups and downs. The first, “The MVP”, is simple and fast, and it will get you the quickest minimal viable product. The second method, “For the Grownups”, will provide you with a start for a fully production ready environment. Both of these will suffice for the rest of our road tripping blog.

The MVP

This process uses a Vagrant box to deploy a ScaleIO cluster. Using the EMC {Code} ScaleIO vagrant Github Repository, checkout the ReadMe to install ScaleIO in less than an hour (depending on your internet of course :smirk: ). Make sure to read through the Clusterinstall function of the ReadMe to understand the two different ways of installing the ScaleIO cluster.

For the GrownUps

This process will deploy ScaleIO on four separate Ubuntu machines/VMs.

Checkout The ScaleIO 2.0 Deployment Guide for more information and help

  • Go to EMC Support.
    • Search ScaleIO 2.0
    • Download the correct ScaleIO 2.0 software package for your OS/architecture type.
    • Ubuntu (We only support Ubuntu currently in CloudFoundry)
    • RHEL 6/7
    • SLES 11 SP3/12
    • OpenStack
    • Download the ScaleIO Linux Gateway.
  • Extract the *.zip files downloaded

Prepare Machines For Deploying ScaleIO

  • Minimal Requirements:
    • At least 3 machines for starting a cluster.
      • 3 MDM’s
      • Any number of SDC’s
    • Can use either a virtual or physical machine
    • OS must be installed and configured for use to install cluster including the following:
      • SSH must be installed, and be available for root. Double-check that passwords are properly provided to configuration.
      • libaio1 package should be installed as well. On Ubuntu: apt-get install libaio1

Prepare the IM (Installation Manager)

  • On the local machine SCP the Gateway Zip file to the Ubuntu Machine.
  • SSH into Machine that you intend to install the Gateway and Installation Manager on.
  • Install Java 8.0
  • Install Unzip and Unzip file
  • Run the Installer on the unzipped debian package
  • Access the gateway installer GUI on a web browser using the Gateway Machine’s IP. http://{$GATEWAY_IP}
  • Login using admin and the password you used to run the debian package earlier.
  • Read over the install process on the Home page and click Get Started
  • Click browse and select the following packages to upload from your local machine. Then click Proceed to install
    • XCache
    • SDS
    • SDC
    • LIA
    • MDM

    Installing ScaleIO is done through a CSV. For our demo environment we run the minimal ScaleIO install. We built the following install CSV from the minimal template you will see on the Install page. You might need to build your own version to suit for your needs.

  • To manage the ScaleIO cluster you utilize the MDM, make sure that you set a password for the MDM and LIA services on the Credentials Configuration page.
  • NOTE: For our installation, we had no need to change advanced installation options or configure log server. Use these options at your own risk!
  • After submitting the installation form, a monitoring tab should become available to monitor the installation progress.
    • Once the Query Phase finishes successfully, select start upload phase. This phase uploads all the correct resources needed to the nodes indicated in the CSVs.
    • Once the Upload Phase finishes successfully, select start install phase.
    • Installation phase is hopefully self-explanatory.
  • Once all steps have completed, the ScaleIO Cluster is now deployed.

Using ScaleIO

  • To start using the cluster with the ScaleIO cli you can follow the below steps which are copied from the post installation instructions.

    To start using your storage:
    Log in to the MDM:

    scli --login --username admin --password <password>

    Add SDS devices: (unless they were already added using a CSV file containing devices)
    You must add at least one device to at least three SDSs, with a minimum of 100 GB free storage capacity per device.

    scli --add_sds_device --sds_ip <IP> --protection_domain_name default --storage_pool_name default --device_path /dev/sdX or D,E,...

    Add a volume:

    scli --add_volume --protection_domain_name default --storage_pool_name default --size_gb <SIZE> --volume_name <NAME>

    Map a volume:

    scli --map_volume_to_sdc --volume_name <NAME> --sdc_ip <IP>

Managing ScaleIO

When using ScaleIO with CloudFoundry we will use the ScaleIO REST Gateway to manage the cluster. There are other ways to manage the cluster such as the ScaleIO Cli and ScaleIO GUI, both of which are much harder for CloudFoundry to communicate with.

EOF

At this point you have a fully functional ScaleIO cluster that we can use with CloudFoundry and RexRay to deploy applications backed by ScaleIO storage! Stay tuned for our next blog post in which we will deploy a minimal CloudFoundry instance.

Cloud Foundry. Open Source. The Way. EMC [⛩] Dojo.

 

 

From Predicting Agile to Agile Predicting The need for #NoEstimates fades when no estimate need be heavy-weight to be accurate.

The need for #NoEstimates fades when no estimate need be heavy-weight to be accurate.

Luke Woydziak

Luke Woydziak

Director of Engineering at EMC
Luke Woydziak
Luke Woydziak

Often Agile teams shun the notion of predicting a date. After all, for teams to make a prediction seems anti-Agile. There is even a #NoEstimates movement afoot. However, in business and in my experience giving some ballpark idea of when something will finish is not only beneficial but also often required.

Estimating accurately is surprisingly difficult as items have varying levels of complexity, certainty, size and dependencies. At #EMCDojo, we believe in providing a realistic date for the various stakeholders of the project. I want to show you a couple of methods we use to do that.

Armed with these methods, I think you will find that the need for #NoEstimates fades when no estimate need be heavy-weight to be accurate.

Let’s get started. We practice the weekly XP practice of an Iteration Planning Meeting. This is where the journey begins. During this meeting, we look at items on the backlog do an engineering analysis to scope, add detail, validate assumptions and address open questions. After such analysis, we Roman Vote on the point value in less that 30-seconds per item.

A common scale of 3-points is often used to point the story (as a team we selected Fibonacci, but in my experience as long as this is held constant, the discrepancies are negligible). We enter these values into Pivotal Tracker as it is a great tool for Agile projects in that it automates the velocity calculation.

The week progresses with pairs of engineers pulling the top priority stories off of the backlog and working them to completion (with unit/integration and system automated tests). The Technical Product Owner for the team will accept or reject the story depending on the actual functionality matching the desired behavior. During this time, Pivotal Tracker will automatically track and calculate velocity and various other metrics.

Below is an analysis screenshot from a live project in progress with the CPT team. You can view the project at https://www.pivotaltracker.com/n/projects/1518687

Analytics

 

As you can see, the tracker reported velocity was 6 points during the month of March 2016.

Velocity

 

While the velocity is interesting, the real value comes when you observe it over time. Again Pivotal Tracker will help you with this. By clicking on the velocity report, you can view a more detailed analysis.

VelocityReport

 

The most interesting data point in this screen is the standard deviation (σ). We use this measurement to establish a high confidence interval (CI) and a reasonable CI for a given prediction (assuming a normal distribution, which is arguably a very big assumption). If you are performing sophisticated business modeling, these are the numbers you can plug-in to model confidently with.

StdDev

One word of caution:

Velocity is extremely susceptible to gaming. So I would strongly recommend against using it to compare across teams. It is far more useful as a predictive element as opposed to a diagnostic element.

 

In our case, we extensively use both epics and releases. You can view and export both as spreadsheets.

Releases:

Releases

Epics:

Epics

 

When you have exported the data, you will get a spreadsheet like ours of releases (if you use releases, however, you can apply the same analysis to epics):

Screen Shot 2016-03-10 at 3.39.07 PM

 

Zooming in on the projected column show us the projected completion date as calculated by Pivotal Tracker:

projected

 

This is a raw prediction; you’ll need to adjust it with the standard deviation (σ) and some calculations. First, let’s calculate the σ adjustment to get a reasonable CI:

  1. Find the velocity (6)
  2. Find σ (2.2)
  3. Calculate the multiplication factor:
    1. v / (v – σ) = adjustment
    2. 6 / (6-2.2) = 1.579

You can apply this adjustment to the time duration from now until the raw prediction in days to get a reasonable CI projected date. For example (the date that we took this measurement was on 3/10/16): The first release “V1 Volume Manager Complete” was projected to finish 18-days from then on 3/28/16. 18-days multiplied by the adjustment is ~28-days. Add 28-days to 3/10/16 and you get 4/7/16.

You can apply the same to get a high CI by using 2σ:

  1. Find the velocity (6)
  2. Find the 2σ (4.4)
  3. Calculate the multiplication factor:
    1. v / (v – 2σ) = adjustment
    2. 6 / (6-4.4) = 3.75

Now you can begin to see how certainty affects the calculation. The breakdown is as follows:

  • Projected: 3/28/2016
  • Reasonable: 4/7/2016
  • High: 5/16/2016

You can add the calculations to an Excel spreadsheet with the following formula: “=(((Projected-Now)*Adjustment)+Now)”

Screen Shot 2016-03-23 at 9.28.47 AM

 

Zooming in you can see the new columns:

adjustmens

 

Now you have some options when communicating predictions and planning non-development, but related activities. With the assumption that this is a normal distribution, the σ and 2σ adjustments represent 68% and 95% respectively. I deliberately used reasonable and high in place of those numbers as I think there is reasonable doubt about regarding the shape of the distribution. Of course, you could manually track those numbers and increase measurement quality. Also, note this is very project specific.

Let’s see how this all worked out. The first release “V1 Volume Manager Complete” was renamed to “CF Summit Demo Day” and completed on 5/26/2016 versus the high confidence date of 5/16/2016.

finalFinish

 

We were 10-days off of the high estimate. So what happened? Well as with all projects we discovered additional items/stories and most likely it’s not a normal distribution.

So we learn velocity alone will only get you so far and doesn’t account for the incoming rate, but for most projects two-weeks variances is within the ballpark. We used this method to plan for presenting a demonstration of Legacy Application support functionality at the Cloud Foundry Summit 2016.

Likewise, you can use this method to make lightweight and reasonably accurate estimates and go from worrying about predicting Agile to making Agile predictions.

Can we do better?

In my next post, I’ll discuss another method, that while it is a bit more complicated and labor intensive, it can decrease the variance and is flexible enough for you to apply across projects easily.

Vegas Baby! EMC Dojo at EMC World 2016 EMC Dojo at EMC World 2016

EMC Dojo at EMC World 2016

EMC Dojo is at EMC World!

Come check out our sessions and play #Dojosnake! Scroll to see more!

What’s up at our Booth?

Come to booth #1051# to see what the EMC Dojo is up to! Learn more about persistence on Diego, UniK unikernel support for Cloud Foundry + Docker, RackHD CPI, & our other OSS Cloud Foundry projects!

Want to try pair programming? Give it a try at our booth! See how easy it is to $CF push apps to Cloud Foundry & pair with us on #Dojosnake! Won’t be able to make it to Vegas this year? Then see if you can beat the high score and play #Dojosnake! Make sure you tweet and follow @EMCdojo to get on the leaderboard 🙂

Screen Shot 2016-05-02 at 9.01.16 AM

If you will be in Vegas, come to one (or more!) of our sessions listed below.  Hope to see you there! (more…)

Tour the Cambridge #EMCDojo Take a Virtual Tour of the EMC Dojo, Brian Roche Sr Director of Engineering

Take a Virtual Tour of the EMC Dojo, Brian Roche Sr Director of Engineering

Brian Roche

Brian Roche - Senior Director, Cloud Platform Team at Dell EMC. Brian Roche is the Leader of Dell EMC’s Cloud Platform Team. He is based in Cambridge, Massachusetts, USA at the #EMCDojo.

The Dojo is “the place of the way,” the new way that we develop software in today’s world. It’s where we contribute to open source Cloud Foundry. It’s where we work with customers to build software.  It’s where we practice lean software development and continuously innovate to solve customer needs.


Why Open a Dojo?

The new EMC-Pivotal Dojo is our response to today’s rapidly changing world.  EMC has established an East and West coast presence to contribute to open source software (OSS), specifically Cloud Foundry.  We know firsthand the transition to devops and the cloud is not easy.  Visitors to our Dojo can see all of the steps involved in this new way of software development. They can see lean methodologies in practice every day. We employ XP (extreme programming) and TDD (test-driven development) to support continuous delivery. This enables us to innovate fast and learn quickly.  This rapid innovation and quick delivery is exactly what is needed to achieve a competitive advantage, and keep it.

 

If you can’t come visit the dojo, we’ve prepared the next best thing; a short video tour of the dojo for you.

 

 

At the New EMC Dojo, App Developers Learn by Doing EMC-Pivotal Dojo, Brian Roche Sr Director of Engineering

EMC-Pivotal Dojo, Brian Roche Sr Director of Engineering

Brian Roche

Brian Roche - Senior Director, Cloud Platform Team at Dell EMC. Brian Roche is the Leader of Dell EMC’s Cloud Platform Team. He is based in Cambridge, Massachusetts, USA at the #EMCDojo.

There is a secular shift at play within the IT industry. Traditional markets are eroding rapidly. As organizations seek to innovate using new digital business mediums, many are moving their infrastructures to the cloud. A major challenge they find is that building cloud apps not only means a whole new set of tools, but also a new mindset. To truly embrace any new way of doing things requires a commitment to learn by doing, which is why we are proud to announce the official opening of the new EMC – Pivotal Dojo in Cambridge, Massachusetts.

The Dojo is “the place of the way,” the new way that we develop software in today’s world. It’s where we contribute to open source Cloud Foundry. It’s where we work with customers to build software.  It’s where we practice lean software development and continuously innovate to solve customer needs.

Building Software for the Cloud

The cloud is a relatively new delivery model, but customers still need to maintain the same rigorous quality, security and up-time SLAs expected in the on-premise world.  Cloud Foundry represents the best-in-class technology that customers can trust to run their businesses in the cloud.  More than just technology, it is a development platform supported by lean practices and methodologies that lead to high quality and continuous rapid innovation.

(more…)

Digital Transformation – Learn by doing Brian Gallagher, President EMC Cloud Foundry Dojo

Brian Gallagher, President EMC Cloud Foundry Dojo

Last week we held the official opening of the EMC Cloud Foundry Dojo in Cambridge, Massachusetts. The term ‘dojo’ is a Japanese word that translates to ‘the place of the way’. In our dojo, software developers learn and contribute to Cloud Foundry, the leading open source platform for Cloud Native Applications. Dojo 1The Cambridge dojo is also co-located with Pivotal Labs to help customers develop these applications via modern software practices. The pairing of cloud software and cloud platforms are key ingredients in leading businesses through their digital transformation journey.

Why is the dojo opening a significant milestone for EMC? First, it underscores EMC’s commitment to open source software. Open source is a key purchasing criteria for 3rd platform applications and infrastructure. During the second half of 2015, EMC emerged from a non-participating company to one of the top contributors to the Cloud Foundry open source. EMC is helping to enhance the governance, risk, and compliance requirements of Cloud Foundry for enterprise businesses.

Second, it demonstrates EMC’s ability to transform itself via a DevOps model. Cloud Foundry’s methodology is a combination of the ‘best-of-the-best’ modern software development practices including Agile, Lean, Extreme Programming, and CI/CD. All contributors to the open source community follow this ‘way’ of development everyday.

(more…)

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.