by John Turner
Posted on February 28, 2014
Following on from my recent post, PaaS and Continuous Delivery - My 12 Month Journey, I wanted to delve deeper into the lifecycle of the staged delivery pipeline. When working in a heterogeneous technology environment there exists a requirement to support multiple language runtimes, application containers, message brokers, storage engines etc. For this reason, the lifecycle must be abstracted from the implementation technology.
For the remainder of this post I will propose a number of stages and the steps within each stage.Read More
by John Turner
Posted on February 13, 2014
Continuous Delivery, Configuration Management, DevOps, PaaS
I have spent the past 12 months building out an enterprise Platform as a Service (PaaS) and Continuous Delivery (CD) capability. It’s been a challenging journey but one through which I’ve gained many valuable insights. We’ve created a very impressive capability that allows us to declaratively define application topologies and have that application delivered to production via a fully automated staged delivery pipeline. That’s quite a jargon filled statement but I’ll explain what it means throughout the rest of this post.
Before describing what we have been working on and the capability we have created, I wanted to talk about why we set out to build this capability.
In The Beginning
My background is in application development; specifically, I have worked most of my career in Java development building enterprise Java applications in their various forms and guises. Throughout this time, the way in which I’ve seen development, operations and infrastructure teams interact has been very much the same. The interactions have been dictated by the organisational structure and within that organisational structure the goals and activities of those groups have been very poorly aligned.
The widespread adoption of agile methodologies has seen organisations focus predominantly on the alignment of ‘the business’ and the development functions they depend upon. As a result, there have been significant steps made toward building a shared understanding of the business objectives and how development functions deliver upon those objectives.
Using process mapping systems such as Kanban, it is relatively trivial to demonstrate the impact of this alignment on the flow of work through development as the bottlenecks within the organisational system change over time.
The result of this insight was that we targeted the bottlenecks that related to software build activities (i.e. within our area of comfort and control). This further exacerbated the turbulence in the flow of work related to software delivery activities. Importantly, Kanban allowed us to identify and quantify the impact of those bottlenecks on the efficiency of the organisational system as a whole.Read More
by John Turner
Posted on September 17, 2013
CDC, CQRS, DDD
Today in business, we are seeing with more and more regularity that the young upstart is out manoeuvring the established players in multiple verticals. In the automotive industry we see the established players looking over their shoulder at companies such as Tesla. In banking we see new and innovative funding models as well as a relentless drive to reduce transaction costs in the area of payments. And in entertainment we see low-cost streaming services disrupting the TV, film and music markets.
The reason we often hear cited is that incumbent players have grown fat of the land and now they are slow and cumbersome, unable to adapt quickly to evolving market demands. Some of that fat takes the form legacy systems that have become behemoths over the years.
It’s easy to defend most of those legacy systems. They work and they have been working for years. They often enforce business rules and logic that have been forgotten, even by those with the longest tenure. They don’t cost anything either because most of the cost has been incurred years ago. That is of course unless you want to change them…and you will!
Many such systems are the heartbeat of their organisation and as such they are changed with much trepidation. Most of those who knew the system well have left the company, retired or are at one with their maker. Those who remain are as lethargic and expensive to maintain as the system themselves. So what options are left? One such option is to build a facade using Domain Driven Design (DDD), Change Data Capture (CDC) and Command Query Responsibility Segregation (CQRS).Read More
by John Turner
Posted on July 23, 2013
Today, there is a lot of discussion focussed on cloud computing and infrastructure as a service (IaaS) but this is still an area that is little understood by many in the enterprise. It is of no surprise that enterprises are slow to adopt and adapt to new concepts and technologies as their sheer size creates inertia. Marc Shedroff, VP of Samsung Open Innovation Center, provides us with some insight into this phenomenon in his article ‘Why Don’t Big Companies Innovate More?’.
In the not too distant past, most enterprises followed an extensive and involved process to provision their infrastructure requirements. This might have looked something like this:
by John Turner
Posted on March 11, 2013
Continuous Delivery, Continuous Integration
ThoughtWorks recently published a paper that proposed a maturity assessment model for continuous delivery. Technology led companies continue to eat the lunch of traditional companies who are struggling to innovate at the same pace as their younger and more dynamic counterparts. Companies such as Netflix, Amazon, Google and Apple strive to reduce the cycle time from concept to reality so are able to give their customers what they want before any of their lumbering competitors.
Even more galling, they share how they are achieving these short cycle times knowing that the incumbents simply don’t have it in their DNA to behave in this way. Going even further, they ([Netflix][http://techblog.netflix.com/] in particular) even open source the software that enables them to do what they do…I can just imagine their smug little faces as they say ‘follow that old man!’. The ‘old man’ just doesn’t understand that it is not enough to be technology enabled because today ‘the custom software that you create will increasingly be part of your competitive edge’.
These old men are set in their ways. They find comfort in the routine that they have become used to over the years. They don’t even understand what the kids these days are talking about! You’ll still call around for tea because you feel a little guilty about leaving them behind. You’ll listen to their stories about how it used to take ages to release to production; how making a schema change was not something to be taken lightly. You’ll do this because you feel sorry for them.Read More