microservices pattern language – live blogging from spring days

Microservice s Pattern Language
Speaker: Chris Richardson – @crichardson
See list of all blog posts from conference

Modern software development:moving fast and not breaking things!
Do this with DevOps, Continuous Deployment/Delivery and small autonomous teams

Monolith

  • Not an anti-pattern because it makes sense at one point
  • Can deploy frequently at the beginning
  • Then it grows. Quickly
  • Then ball of mud
  • Get stuck with obsolete tech stack that used when started project

Microservices

  • Architectural styles
  • set of services
  • loosely coupled
  • organized around business capabilities
  • tackle complexity through modularization
  • Improved scalability is secondary (“monoliths can scale quite well”)
  • Each service has own private data store/schema (doesn’t need own database)

Benefits

  • Once agree on APIs cn develop with less communication and integration
  • Easier to understand develop/test
  • Less potential for jar hell
  • Start up time faster which imporves MTTR (mean time to recover)
  • Know who owns each service – with monolith, everyone is responsible so nobody really is
  • Can fail safely with new technology because only affects one service

Downside – Complexity

  • Now have messaging/remote calls
  • Deal with timeouts and partial failures – circuit breaker pattern
  • Multiple databases and transaction management – need series of local transactions
  • Queries more complicated – can’t just join with SQL. Need to call multiple APIs or replicate data
  • Need a lot of automation; a lot of production applications /services
  • New feature needs multiple services to be deployed in right order

Your monolith will grow forever and never get better. Automation makes microservices better. But need some automation as pre-req for successful microservices

Pattern language

  • To solve architectural problems
  • See patterns on microservices.io
  • Chris writing a book on the topic – currently available through Manning Early Access Program (MEAP)
  • Example of a pattern for dealing with querying data from multiple sources: CQRS – command query responsibility segregation – see CQRS pattern on web
  • Chris is still creating new patterns so remember to check back on the site

Overall, I like that more of the presentation was about microservices than the patterns themselves. It shows why this is important and gives the background to read the patterns. I like the patterns he chose to show.

Test smells breakout at the server side java symposium

While I’ve read about this topic a lot, I wanted to come to do the topic to see how Lasse Koskela presents. [I’ve learned so much from him over the years as a moderator at coderanch ] He speaks in the same voice that he writes – casual and easy to follow. I really liked the format: present an anti-pattern and have the audience brainstorm what is wrong with it/how to improve it.  I also like his speaking style, gets away from the podium, engages with the audience, good pace, etc. And good use of humor to get participation going “I’m from Finland, we’re ok with silence”

“it’s a good thing that tests break,it means they are testing something that changes”. “as long as they don’t break for the wrong reasons”

Assertions

  • Primitive assertions – Custom assertions, assertStringContains
  • Overly broad assertion – like the golden master, but not intentional, dangerous because have to change if any small detail changes, more specific are preferred
  • Irrelevant assertions – assert not null and then assert a property on the non null object – let junit throw the null pointer

Organization

  • Split personality – Tests two things, many ways to see – var reuse, calling method under test twice, a blank line for two blocks of code
  • Split logic – don’t use information from elsewhere, it is a mystery to the reader of the test what is happening
  • Note: sometimes a refactoring makes things worse and you need to go back or explore another solution.  Better to fix the problem with the refactored code because it is likely better than the original.

Transparency – how readable is it

  • Setup sermon – Extract overly long/complex setup methods, revisit design to get file system out of the picture, avoid magic numbers “why four”
  • Use multiple setup methods to make clear what is being setup
  • Big string – building an XML file in java is bad.  Instead of. Putting in external file, could create method that takes parameters and builds the XML file. This helps because can clearly deduce the important info without reading through reams of XML.

Maintainability

  • Absolute file path – Don’t depend on the environment, platform specific makes harder. For files could use a temp directory that you wipe clean. That way there isn’t test residue
  • Also, relying on path messes up paths when checking out from a branch, use relative path instead. Or getResourceAsStream()
  • Pixel perfection – a lot of assertions for each pixel in an image, any small change breaks the test even if not meaningful (like golden master pattern). One approach is to make the burden of maintaining less. Grab good image and compare to new image. Tis makes it obvious that it a golden master and requires visual inspection. Another way is to fix the test to use the proper language in the assertions.  that tests the lines are connected without testing the pixels directly  To implement, write custom matcher to test pixels by relative position.
  • Lasse feels adding assertion messages makes the tests harder to read and doesn’t add clarity.

I like how Lasse showed the benefits of looking at your old code. It shows that you’ve learned a lot since then.

I like that some of the examples were in languages other than java. I also learned a lot!  Sorry Scott: I wanted to be at your session, but this one was awesome!