SpringOne live blog – going cloud native at Comcast

Going Cloud Native at Comcast
Speaker: Todd Migliore

For more posts from Spring One 2017, see the Spring One blog table of contents


  • 10 year old services
  • Had to scale platform has a whole with physical services. Couldn’t scale one service
  • Shared release calendar for 15 dev teams.
  • Only did deployments once a month.
  • Took two hours to deploy all services.
  • Had to deploy in middle of night to minimize impact
  • Three level support team. Ops team split from dev and test teams. Finger pointing when there was an outage.
  • Data store was active (east coast) and passive (west coast.) There was a 60 minute outage to transfer. Instead would troubleshoot for an hour before giving up and having another hour outage.

The challenge

  • Needed to transform while still running

The approach

  • Held a submmit
  • Got smartest folks in room to answer “how are we going to get out of this mess”
  • Someone suggested migrating apps to cloud
  • Hard to move to cloud. WebSphere/WebLogic, rack database, monolith
  • Then someone suggested microservices

Microservices – why it should be small

  • Agile – deploy to prod in minutes
  • Elastic – scale in minutes
  • Resilient – survive outages form back end dependencies
  • Distributed – automatic failover
  • Event driven – stream data to other services
  • Developed and run by a single team
  • If you service talks to more than one dependency, it is not a microservice
  • Need to define what that one thing is for your microservice
  • Should own its own data.

Note: my session was right after this one so I spent the end getting ready for mine.

SpringOne live blog – Productize Your Service

Productize your Services – a path towards effective microservices development
Speaker: Stephan Hagemann (Pivotal)

For more posts from Spring One 2017, see the Spring One blog table of contents


  • When do one big thing, split it into a bunch of smaller things
  • Who needs to talk to whom to see what they want to do


  • Boat analogy – agile is turning gracefully as quickly as need to
  • We don’t know what’s coming
  • Try to build in the right way


  • Less costly ways of learning what need to learn in order to know doing right thing
  • Ex: computer model before build physical object
  • Boat analogy – small boat, prototype

User centered design

  • Create solutions in context within constraints
  • Think about requirements
  • Constraints change over time. Ex: technological advancement
  • Through iterations, winner shapes next set of options

Two Speed IT – bad idea

  • Made slide red because bad idea
  • Idea that change is hard so will change customer facing apps first and leave the old stuff alone
  • Speed 1 – nothing happening
  • Speed 2 – go fast and then get stuck when need to wait for something at speed 1
  • Forcing people to use your API doesn’t work. That’s where shadow IT comes from.

Productized service

  • Nice story about out of date docs, people who changes jobs and eventually finding out a service wasn’t implemented. Then he showed the code. [I missed how the service got implemented. Or maybe that it was implemented and never went to prod]
  • Pivotal has marketplace so can find available service
  • Example of a nice service – see if license is valid for your artifacts

SpringOne live blog – scaling the build process at home depot

Scaling the Build Process at Home Depot
Speaker: Matt McKenny & Jeff Millimek

For more posts from Spring One 2017, see the Spring One blog table of contents

  • Previously had regimented build process – had to be Java on Tomcat with Eclipse.
  • Now can use almost anything.
  • Shift to culture of expermentation
  • Focus on speed and feedback
  • Opinionated about not having an opinion


  • Need to change tools/stack as learn
  • Used to have one Enterprise Jenkins for everyone. People wanted different plugins so became special snowflakes.
  • With Cloud can get new Concourse CI cloud server in 8 minutes vs ticket and waiting
  • Provide example pipelines – search and replace example repo with team one and good to go [isn’t this a lot of repetition?]
  • Slack – easier to discuss with remote people – communication and info sharing. Worked with managers to make sure everyone had a certain amount of time to spend on slack.
  • In person, use stickies

For publicly traded companies

  • track actuals of labor or average over a period of time
  • SOX – move away from waterfall tollgate and build new change management approach with pipelines

Lessons learned

  • No single owner of how do CI. Need to include developers. Everyone be part of the conversation. Less likely for everyone to standup own thing.
  • At scale, individual choices harder. Allow for common path and then iterate on snowflakes.
  • Free/cheap on demand servers
  • Secure social collaboration
  • Work with teams who want to change
  • 300+ concourse servers. Also have Jenkins, Drone, TeamCity