Going Cloud Native at Comcast
Speaker: Todd Migliore

Problems

• 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.

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

Services

• 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

Agile

• 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

Lean

• 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

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

• 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

Tools

• 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