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

Crossing the CI/CD/DevOps Chasm
Speaker: Miranda LeBlanc (Liberty Mutual)

Goals

• Cloud native enterprise – continuous delivery of valuable software
• Embrace DevOps – culture of trust, safety and confidence
• Agile
• Microservices architecture

Working with services/teams

• Operate in an open source fashion
• Can submit pull requests to other teams
• Liberty CloudForge – internal tooling team to support business facing teams.

Security

• Need to protect medical and financial data
• Build safety, security and compliance into pipeline

Goals vs Reality

• Developers focused on own team/business units.
• Not ready to do open source like development.
• Not ready to look at chasm let alone cross it.

Approach

• Started experimenting with tools and standing up CI.
• Then progressed to static analysis/code review.
• Then DevOps and automated deployments
• Then PaaS
• Then to Prod in 5 minutes

MVP

• Focus on MVP on every feature/story
• Minimal feature is a proof of concept
• Want MVP that will delight customers

Challenges

• Removing features that aren’t delivering value (or not delivering value anymore)
• Growth – going from 10-50 people. Everyone can’t know everything.

Lessons Learned

• CI/CD requires real software engineering skill – learning Maven/Gradle, automated testing, etc.
• Define key metrics up front and use them – ex: released a bug to prod because focused on unit test coverage
• Culture and behaviors matter – ex: get whole team on board with new wait of thinking. Want to avoid asking what date trying to hit. Roadmaps are for conversations not commitments.

• Cyclic – digital transformation yet hardly ends well
• Think about how to program your business
• Start by moving things you do yourself that aren’t your business – ex: hosted email
• When people have ideas, they don’t want to be told to open a ticket

Delivering value

• Doing software well is managing chaos on behalf of users
• Top user stories
  • User would like software to work
  • User would like to accomplish a goal
• Deliver value reliably in small batches – allows to hypothesis/validate quickly/see if worked for user
• When you succeed in solving a problem “merry christmas; here’s another problem to solve”

IRS

• used to have a call center
• problem because people don;t like calling the IRS
• only 37% of calls even got through
• tried feature where could revisit past – people didn’t like either and still called. But fast feedback loop cycle so could move on to next approach
• finally learned all people wanted was to know how much they owe

Agile/teams

• 25 years later, agile practices are still not standard
• Look at which practices each team doing; not how many Certified Scrum Masters you have.
• Waterscrumfall or wagilefall – still doing big upfront analysis before get to team level
• Organization needs to support agile teams
• DevOps team is old name
• Have all roles need on team; fully dedicated to product. Build up expertise and shared knowledge
• Have standardized platform that takes care of basic needs to can focus on delighting users vs needing everyone to be a full stack engineer
• Work closely together whether in person or over video conference. In person probably is better.
• Easy to get stuck doing research when working by self. Easier to stay on task and work 4-6 hours a day.

Operations

• If change nothing, system will stay up and running.
• Developers are the ones who write the bugs.

Scaling

• Don’t be overly ambitious at first. Start with low-risk apps
• Real apps. Not the poor cafeteria app.
• Skunkworks/quarantine yourself. Limit failure.
• Internal marketing – not just email.

Also see booklet: https://cote.io/2016/11/28/cloud2/