Bootstrapping DevOps


Recently there was a very good meetup organized by Boston DevOps meetup group. One of the best talks was given by Anthony Accardi on Swipely’s implementation of DevOps!

Anthony’s talk focused on the similarities between testing and deployment as they pretain to the culture of the teams. Their release includes the following:

  1. Push code to GitHub
  2. Have a C I.service build a container
  3. Configure the container with their instance mgmt app
  4. Push to AWS

I had not realized at the time, but Swipely actually built a great app called Aerosol to manage the instances on Aws. They teak Martin Fowler’s advice and wrote the app in a Do main Specific Language (Dsl). I would highly recommend people review this code for a great example of automating code and implementing a comprehensive DSL.

Generally when I think about the culture on our project team, I usually reflect on what we do right now and what we could be achieving with the night culture in place. Yet Antony breaks this down – that there are multiple levels of culture. Each new buy-in achieved, results in h new behavior. The sum total of all these behaviors is the culture we want.




Code Phage – Coding the Future

Roomba Path


At ACM SIGPLAN‘s recent PLDI, Programming Language Design and Implementation, conference several MIT researchers presented an automated bug fixing tool, Code Phage.

What really makes this tool stand out is that it is language agnostic, and doesn’t even need the source code! It will figure out what the other program is doing and implement that check with my own application.

The basis of this is in good design – that I’ve decoupled my classes so that for example my image processing class only deals with just that – processing images. Now I’m not the first person to process images and there are hundreds to thousands of projects that do this. Have I thought of all use cases? Not a chance – but if you took all the projects you should have a really robust set of use cases.

Code Phage relies on this – that I have a defect that someone else has coded correctly. It would need a database of these applications and the inputs that work for each.

Now with this dataset, I provide it an input that runs successfully in my application, the baseline, and an input that crashes it. Code Phage will search its database to find where both inputs are successfully processed. This stage is known as Donor Selection.

With a Donor application selected, Code Phage maps out the branching the application takes as it processes the baseline input. The idea is that when the error input is processed, the donor application will deviate from the baseline at a check that my application is not processing.

The genius of this program then comes into play, the researchers were able to map this process branching independent of the donor application, and by performing the same process branching on the recipient code, i.e. my application,it can pin point where this additional branching is required. Finally it can convert this branching logic into my specific language and update the source code successfully.

As the trend doings further decoupling, moving towards micro-services etc, this will really take developers out of the weeds of their programs and allow the to concentrate far more on the design and flow of their application.

The Stuff Behind the Fluff – A Recap of NFJS!



Last weekend saw the traveling roadshow of a technical conference, No Fluff Just Stuff Software Symposium Tour, arrived in Boston and I got to attend!

The tour features a number of fantastic speakers and the only issue is the problem trying to figure out which sessions to attend. I was able to cover a fair few which I hope to detail in depth in future postings.

I got an introduction to lambdas and streams by’s Venkat Subramaniam. It was great to see Venkat in person and interesting how his style was so similar to his talks online, foregoing slides in favor of live developing! He really drove home the benefits of functional programming with the following:

List<Integer> values = Array.asList(1,2,3,5,4,6,7,8,9,10);
int result = 0;
for(Integer value: values) {
	if (value > 3 && value % 2 == 0) {
		result = value * 2;


And then converted into the following:

List<Integer> values = Array.asList(1,2,3,5,4,6,7,8,9,10);
      .map(e->e * 2)

I caught Danny Brien‘s talk on HTML 5 Mobile Apps which took, for me, the unexpected turn of utilizing  html5 elements with javascript and CSS to take a packaged web app (Cordova/PhoneGap) and use it to behave more like a native application.

The slickest part of his talks was seeing Ionic in action as a method of live development. Alter your files, save, and the phone automatically reloads the page with the changes. The time cost of pushing native apps is certainly noticeable and this could help loads here!

Craig Walls gave an introduction to Reactor, a Spring framework. I struggled to see how to incorporate it into our tech stack at work, but the overall aim  of it is designed to allow a spring application process large quantities data to trigger on events. It does change my impression of Spring as a powerful, but slow and bloated framework!

I got a terrific introduction into the Java Messaging System by Mark Richards! He has covered JMS 1.1 and 2.0 across multiple books and O’Reilly videos. This was great in covering the use of JMS and the advances that came with JMS 2.0, advances that were 13 years in development.

I will be digging into Go as a result of Matt Stein‘s talk on Go for Java Devs. He covered the basics of the language, highlighting the differences in syntax between Go and Java.

Raju Gandhi covered both Gradle and Angular JS. It was great to finally get a proper introduction into both of these technologies. Gradle turns out to be incredible powerful, providing the build instructions of Ant/Maven, but allowing you to drop into Groovy to program to create even more complex tasks. Angular JS blew me away with the capabilities that come right out of the box, the fact we now can program controllers in javascript drives home how mature JS has become.

Kirk Knoernschild opened my eyes to how architecture *should* be done – and gave me my favorite quote of the entire conference,

Architecture that doesn’t match the implementation is a hallucination!

For all the talks, I don’t think any have been as practically useful as Nathaniel Schutta‘s Bulletproof Javascript! I came out of this with a host of tech to implement and use ranging from Node JS to grunt for setting up my code to analyzing it with jsHint and the gorgeous Plato to display code analysis results!

Screen Shot 2015-03-02 at 10.00.00 PM

Screen Shot 2015-03-02 at 9.59.36 PM


The conference will be returning to Boston in September, so I recommend folks check it out!


Nike, Continious Deployment, and Deployment Patterns

The following is a great talk that Nike’s development team gave at AWS re:Invent 2014.

They discuss their move from an unstable and hard to maintain code base towards continuous deployment before finally going to the stage of  providing microservices and how the changes to their technology stack made this possible.

They tried to adapt their strategy the traditional way, and give a status of how it went after each year:

2011 2012 2013
Automation Haphazard and manual based on specific features in a shared environment JUnit/JMeter with coverage requirements but inconsistent results JUnit/JMeter automated and mostly consistent
Product Understanding Very Low High Very High
Engineer Work Cycle 24/7 near 24/7 sane
Time to Deploy a New Feature Months Months to Quarters Weeks to Months
Deployment Quality okay; intense manual validation required with many date misses stable with intended feature sets and bug fixes
Product Perspective Fast and Chaotic Slow and Stable

Even after the 3rd year, they had some observations:

  1. Configuration management still delays our software cycle
  2. Database deployments still too manual
  3. Even small changes have unintended consequences (now caught in testing)
  4. Still moving too slowly
  5. Normalization is the root of all evil
  6. Huge organizational approvals for everything

Some of these sound familiar :)

Nike decided that a paradigm shift was required to resolve some of these issues – to limit the impact of installs they moved to micro-services and altered their deployment pattern, which leads me to the main bit of fun – deployment patterns!

 Blue-Green Deployment Pattern

This is a design where you have two production servers. You deploy the code onto server A and then point all users at server A. For the next release, you deploy to server B and point all users to it. This allows you to only alter the router to restore the previous version.

Blue Green Deployment


Phoenix Deployment Pattern

This is a pattern to minimize configuration drift – the idea that over time, small changes are made on the server that are not propagated – then deploys fail when they find this unconventional configuration. The solution is the frequently re-build the servers off a template. As the users are pointed to the latest environment holding the latest release, and the old environment is deleted. As the new release is ready for production, a new environment is spun up.

Phoenix Deployment

Environment Promotion Deployment Pattern

This takes the Phoenix Deployment to the next stage – at the development stage a new environment is spun up. The entire environment is promoted as part of the development life cycle ensuring that the configuration that was tested will always be the same configuration in production. This is really aimed at environments that are standalone – no external I/O.

Environment Promotion Deployment

Canary Release Deployment Pattern

This is a pretty interesting pattern that was designed with clusters in mind. The majority of the users continue to use the existing release, and a subset are directed to the new release. As long as the users do not face any issues, the release is rolled out to the other users.

Canary Release Deployment Pattern

Dark Launching Deployment Pattern

This is a pattern that was designed by Facebook, and is an attempt to separate the actual install from the release of functionality. The installation would include the complete set of functionality, but this new functionality would not be accessible initially. The functionality could then be rolled out selectively either to validate it before greater usage or so that the impact on performance could be monitored at less than 100% usage.

Dark Launching Deployment Pattern

Hackathon Idea Sketch for Shoveling my Roof…

Terminator Frozen

The Intel IOT Roadshow is coming to Boston and they are hosting a hackathon and letting folks dig into their developer kit, which looks pretty damn cool!

Well I’m awake and been thinking about some of the past projects that have demoed and what might be fun to attempt myself.

A bit of context also now, in case folks have not been following Boston weather :) It has been a gruesome winter so far – major snow fall and freezing cold has led the city to have many problems. One of these problems tends to be snow build up on the roof. The roof can only take so much weight and a number of cave-ins have occurred over the last few weeks – and if you are lucky to get away with a cave-in, you need to worrry about ice-damns forming and causing water to leak into the house.

So a few nights ago I finally peaked at the roof and felt compelled to shovel it.. very..very slowly.. This is something I would prefer never have to do again!

With that in mind I’m playing around with an idea of a articulated mini shovel system – like a roomba for shoveling snow!

A shape is needed that will allow it to move snow, but be able to deal with the high winds the roof gets. With this in mind, thinking multiple mini shovels that rotate around a pole that, when angled into the wind, provides very little surface area for the wind to catch on, and multiple threads on each segment allow it to have good traction.

Intel Hackathon - Page 1


The shovels need to rotate around the central cylinder, shoveling up what was in front/behind, and quickly rotating around so that the snow on the shovel is flung outwards.


Intel Hackathon - Page 2


Need some sort of ball bearing/socket going on here so that the first rotation can return to the neutral position.

Intel Hackathon - Page 3

Intel Hackathon - Page 4


Some of the general ideas of how it would progress – can’t be as aimless as the roomba as it might fall off the roof! Need to spiral around so that it can detect when one segment leaves an edge and is dangling off the side. From there can build up a plan of the roof and how to shovel it.

Intel Hackathon - Page 5

Intel Hackathon - Page 6

Intel Hackathon - Page 7