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

State or Events?
Speaker: Kenny Bastani & Jakub Pilimon

Live coding

• Showed Groovy code using Spock for tests. [didn’t actually mention it was Spock, but easy enough to recognize]
• Wrote tests first for a CreditCard object [nice advantage of tests in Groovy. The methods don’t need to exist and you don’t get red errors as you type so not tempted to write the methods]
• The CreditCard implementation was logical with instance variables.
• Noted that the method to assign the limit is a command with an invariant.
• CQS – command query segregation

Refactoring to events

• Create domain events
  • For name, pick a past tense description of what it does. For example “limitAssigned”. Used same name for method and domain event object (which is passed to method as parameter).
  • Add timestamp to event so know order. That way can determine current state of object.
  • Also need former instance variables (limit) and parameters (amount) as attributes of the new domain event.
  • Similarly refactored to have withdraw(CardWithdraw c) and repay(CardRepay c)
• Keep track of changes and store
  • Dirty context – when change object but haven’t saved yet.
  • Add instance variable for list of domain events. This keeps track of the pending/dirty events
• Create Repository object
  • instance variable with map of unique credit card ids to a list of domain events
  • method to save to map
  • method to load credit cards by replaying all events. Used left fold. “It’s so fancy that Java 8 doesn’t support it out of the box”. Used javaslang.collection.List API to get it.
• Update CreditCard three handler methods to return a references to “this” so can chain
• Added Kafka so could store events (via Topics)
  • Added spring-kafka and kafka-streams to pom
  • Created config class with @EnableKafka
  • Update save method to use Kafka class
• Then switched to Kafka streams
  • @EnableKafkaStreams
  • Created new bean for stream configuration
  • return KTable – key table – aggregate of events from object
• Create controller
  • method to get list of credit cards
• Created scheduler for testing a bunch of credit card transactions

[this was a full house; I barely got a seat. Pivotal handed that well. They found all the empty seats and directed people do them. Even so, there are a good number of people in the back.]