Going Cloud Native at Comcast
Speaker: Todd Migliore
- 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.
- Needed to transform while still running
- 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)
- 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.
- 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
- 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
- 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