Moving to Continuous Delivery and speeding things up, the rate of change have increased at the same time as the cost, size and risk of change has reduced, an DevOps and agile transformation, and a containerization that is very compelling for businesses of nowadays, Adrian Cockcroft explained in his keynote at the Docker conference held in Amsterdam in November.
Looking at ways to speed up the product development process using Continuous Delivery Adrian refers to the OODA loop (Observe – Orient - Decide – Act) explaining that the faster you can get around this loop, the faster you learn something new about your customer and the market, the more agile and competitive you get. Adrian has found that enterprises that do this often find improvement in quality of their products and their ability to learn. In his experience a problem achieving this is that many companies are organised around silos with product managers, developers, QA, etc., each in their own team, and getting something done requires a lot of meetings, a kind of waterfall approach that takes too long. A common solution is to create monolithic delivery groups cutting across the organisation and its silos, but for Adrian this is inefficient since each group is then reinventing their own platforms. Instead he believes teams should be organised around microservices with a separate platform team exposing an API that all other teams use. Adrian emphasizes that this is what DevOps is about, a reorganization of teams.
One thing that happened 2014 was that Docker as a standardised portable container arrived which now is on everybody’s 2015 roadmap. One important reason for its widespread use Adrian notes is its portability and the increase of speed with a container delivery going from minutes or hours into seconds. He also notes that:
Speed enables and encourages new microservice architectures
Looking at some of today’s web scale microservice architectures Adrian has found some common characteristics:
- Brand new microservices are deployed infrequently.
- New versions are deployed automatically and frequently.
- General purpose orchestration is not needed since whole systems are not deployed with all parts at the same time.
- Architectures use hundreds of microservices.
- Each deployment is heavily customized.
Continuing on this the next step Adrian sees is orchestration for standard portable applications based on maybe tens of microservices where new versions are automatically deployed and where scalability and availability is taken care of. He also foresees an ongoing movement from monolithic to microservice architectures.