Trent Gray-Donald

I am the senior technical member of the IBM Java Technology Center team. I was recently the technical lead for the IBM Java 7 project. I have also been responsible for the consumability strategy for the IBM JVM, accountable for tools, education and many aspects of improving the customer experience. I have historically been a team lead for the JavaSE™ JVM team (codenamed J9). Previous efforts include development roles on the VisualAge for Smalltalk and VisualAge for Java teams. Trent holds a Bachelor of Mathematics (Computer Science) at the University of Waterloo, Canada.

April 16th, 2012
10:39 am

Posted by

Trent Gray-Donald
Trent Gray-Donald

In my last blog I talked a lot about encoding patterns and then being able to deploy them in a repeatable manner.  That’s a big advance and certainly helps operations teams deliver code smoothly into production. However, it doesn’t address what happens after that, namely maintenance cycles, emergency security patches, etc… These take considerable time and effort as well as introduce risk that needs to be carefully managed. While it doesn’t sound like a huge problem in isolation, the size of a typical data center means that potentially hundreds of systems may need to be updated on very short notice. This can be a nightmare scenario with considerable manual effort required.

Thankfully the IBM PureApplication System deals with the full application lifecycle at multiple levels gracefully. Every layer of the stack, from hardware firmware up through the OS to the middleware, is clearly aware of what version it is and if there are potential updates. Depending on how you choose to do it, you can update individual components or whole systems at once. Of course, previous versions can co-exist, so updates can be rolled out in stages, and rolled back just as easily in the unlikely case that’s necessary.

The advantages around such a systematic approach to patching are the same as for encoding patterns: because it’s fully scripted, it’s predictable in behaviour and one can be sure patches were applied correctly and will not be lost at a later date. It’s also fast and reduces (or entirely eliminates) downtime: patches are performed on offline master images which are then activated.  When they are ready to use, the system workload coordination components ensure that new systems are inserted in the right places (eg: load balancers know about them) and old systems are removed when new ones are ready. Thus one can effectively perform zero downtime maintenance in a predictable and automated manner.

In summary, this post shows how IBM PureApplication System handles the critical yet often unglamorous job of keeping your systems current.  By using a full system-aware strategy, this approach taken saves time and effort at the same time as significantly reducing risk. It also facilitates zero down time maintenance cycles, which is a huge bonus.

April 12th, 2012
2:39 pm

Posted by

Trent Gray-Donald
Trent Gray-Donald

The history of computing is full of discontinuities that change how we think about computers. Whether it’s the introduction of mainframes in the 1950s and 1960s, or the emergence of RISC architectures in the 1980s, or graphical user interfaces, or app stores, there are always far-reaching consequences. It’s always disruptive, and there’s always ambiguity around the long term value. It’s also sometimes hard to tell the big winners from the also-rans. I believe today marks the birth of the next big winner.

Today’s marketplace is crowded with complicated solutions to complicated problems in many different domains. The trajectory the industry is on is unsustainable: most IT shops spend well over half of their budget simply maintaining existing systems. It takes months to provision and deploy new solutions. Real risk surrounds every change, slowing down change. There’s been an organic growth in an area called “devops”, focusing on codifying the deployment aspects of bringing software through to production. Approaches like that are good, but still quite immature and it’s clear there’s scope for a lot more progress around automation, repeatability, etc…

IBM is announcing a new category of systems based on “expert integrated systems”. I won’t describe the whole thing (see: http://ibm.co/J0ROUO  for more details) but I want to talk a bit about the part that resonates most strongly with me. The IBM PureApplication System family member provides a pattern system (http://ibm.co/J0ROUO) that allows both IBM and 3rd parties (including customers) to encode exactly how they want a given set of products or components to be set up and run. Once this initial encoding work is done, the system can simply deliver copies of this at will, all identical. Because both IBM and over 60 partners have already done patterns, many complicated software systems that used to takes days, weeks or months to install, configure and tune can now be done at the click of a button.

As well as the obvious benefit of saving huge amounts of time when setting up complicated systems, a key value for me is the repeatability. Because all of the configuration information is clearly recorded by the system (and visible to the user), repeatability goes up. Thus once a developer gets their application running in a development sandbox using patterns, they can be sure that it can be successfully deployed with minimal effort into test and ultimately production.

Developer productivity has been suffering over the last several years due to the complexity of setting up necessary software. I see today as an inflection point for productivity – the day when teams are freed from mundane yet expensive tasks surrounding installing and configuring software by hand. Single developers are now able to take various complicated software products, drop them onto a single virtual canvas, wire them together, and then deploy the full solution with a click of a button. This will enable developers to focus on their core job: adding value at the top. I can’t wait to see what people build!

Posted by

Trent Gray-Donald
Trent Gray-Donald

Early on in my career, my technical lead spoke to me about his core philosophies around building strong products.  After talking about the obvious considerations – high performance, high quality, and great features – he went on in what I considered an unexpected direction.  He insisted upon how the product was built (from source code to shipping to the end customer) was critically important to focus on.  At first I didn’t really understand why we were discussing this, but eventually I realized some of the deeper truths in his insistence.

Developers want to spend all day writing code; in reality, they spend considerable time, every day, dealing with the process of software. Whether it’s building or testing a change or shipping an update patch to customers, they spend a lot of time on non-coding activities. For most, these are mundane and low difficulty actions. However, they are fraught with peril as one single mistake (for example, on program configuration options) can destroy quality and predictability, leading to huge problems. It became clear to me that codifying and automating are the steps to go from source code to ship-ready binaries resulting in significantly higher field quality.

In IT today, agility is critical.  The number of ‘turns’ (edit, compile, test/debug) a developer can make in a day is strongly correlated to their effectiveness. Thus, having highly automated systems that can immediately and repeatedly deploy and run software is critical. Many complicated software systems today take days to set up and run if done manually. Again, this is repetitive and error prone work. Thus, teams that focus on streamlining and automating these steps often outpace other equally talented but differently focused groups.

As my career progressed, I’ve seen software systems get orders of magnitude more complicated and yet most teams continue to deploy software the traditional way – by hand. Certainly existing cloud computing and virtualization solutions attempt to provide solutions to parts of the problem, but what they end up missing is quite often the critical ingredient, i.e. product domain expertise.  So you can either have something completely custom yet complicated and unwieldy to maintain, or something quick and simple yet unable to really adapt to your specific circumstances.

How do we get through this seeming impasse?

Behind every robust software system, there is a group of experts and the best practices they have accumulated over time. Now, how can we get these ‘patterns of expertise’ out of the heads of the experts and robustly codify this knowledge? IBM has brought together experts from virtually every corner of the company and is proud to be launching a family of expert integrated systems on April 11. And I’m very excited to be part of the solution.

For more information, please see: http://ibm.co/J0ROUO