TDD for Microservices Architectures – live blogging from spring days

TDD for Microservices Architectures
Speaker: Reshmi Krishna and Vinay Upadhya
See list of all blog posts from conference

Showed Martin Fowler’s testing pyramid (unit, integration, component, end-to-end, exploratory) to set vocabulary

Focus with microservices is contract based testing.

Consumer driven contracts (CDC) let the callers specify exactly what they are interested in from a generic API. If everyone does this, you know who uses what fields so don’t remove something that a caller is relying on.

Spring Cloud Contract

  • specifies contracts with Groovy (but mainly DSL so like data structure). Can use other formats such as XML
  • Looks like BDD – request/response except HTTP level.
  • Contracts stored with app under src/test/resources. Or can store in separate project
  • The producer autogenerates stubs/tests and shares with consumer

Libraries

  1. Spring Cloud Contract Verifier – checks service isn’t breaking any consumer contracts
  2. Spring Cloud Contract Wiremock – wrapper around wiremock (wiremock is an API mocking tool)
  3. Spring Cloud Contract Stub Runner – pulls stubs from maven and run with wiremock

Flow

  1. Client app needs an API/field. Client writes test specifying what need. The test specifies workOffline = true to use local stub
  2. Client implements code to call the microservice that implements the new feature [This was worded a “client implements the feature” which is not what they meant upon a few questions and confused me. With my wording (about calling the microservice and seeing the code it makes sense that the client is not implmenting the feature]
  3. Client clones producer repo and define locally – if needed. Or can use common repo for contracts.
  4. Autogenerates tests/stubs for producer based on contracts. The stubs are wiremock JSON. The tests use JUnit/AssertJ.
  5. Client runs verifier tests – now they pass

If later version of service, update URL with version number so have new requirements.

The PowerPoint felt a bit rushed, but the demo was a good pace. I would have liked more mapping between the points in the flow. It’s a lot to remember. But it did mostly come together in my mind. Especially after I asked enough questions to uncover the a bullet in the flow wasn’t actually what happens. (So confused me) From the questions, I could tell that others in the audience were wondering about some details as well. Luckily, I had the step in this post for reference!

cloud native streaming and event driven microservices – live blogging from spring days

Cloud-Native Streaming and Event-Driven Microservices
Speaker: Marius Bogoevici
See list of all blog posts from conference

Streaming

  • Streaming is processing large quantitiesof data as fast as possible -near real time.
  • Collection of eents – in order
  • Good for real time ELT, predictive maintenance, fraud detection, QoS, etc
  • high throughput/low latency

Microservices

  • Cohesive, organizational allignment (Conway’s law)/li>
  • Development agility – optimized for replacement, enable continuous delivery
  • Failure isolation
  • Granlar resource tuning – can scale specificparts of pipeline

Event driven microservices

  • Communicate thrugh message broker vs http
  • Decoupled
  • Publish/subscribe makes it easy to add new elements

Think about opertional complexity – need to be able to provision/montitor. Want this part to be boring. It’s not the business value. Hence cloud-native; the platform should take care of these concerns.
Support Spring WebFlow- Cloud Foundry, Apache Mesos, Kubernetes, Apache YARN

Spring XD – first incarnation. In 2015, it turned into Spring Cloud Stream/Task/Data Flow.

Spring Cloud stream

  • event-driven microservices framework
  • Built on Spring Boot and Spring Integration
  • Binder abstraction – core of framework – connects channels to messaging middleware of your choice
  • Apache Kafka and Rabbit MQ are prod ready support
  • Based on pipes and filters. The logic is in the fiters
  • Spring Cloud Data Flow

    • Orchestration of services
    • Provides Stream DSL
    • Describe deployment
    • Deploys using SPI (service provider interface)
    • Deployment descritpor to specify what want to happen

    Interesting. And we got to read more Flux code. Appreciating Victor’s talk from yesterday even more! I would have liked if “opinionated primitives” was described more. While I understand what the concept means, I’m not that clear on how it relates to the framework. I also had to Google the term SPI. This might have been a presentation for which I lacked pre-req knowledge. The session felt longer than the others. Checking the log for this blog post, it was a little longer; but not a ton so. I think just too much sitting for me!

    advanced spring boot with consul – live blogging from spring days

    Advanced Spring Boot with Consul
    Speaker: Michael Gendelman @MikeGendelman
    See list of all blog posts from conference

    “when someone writes something clever and leaves, that’s a problem”

    “every time someone logs onto a box at a Fortune 500 company, it is a big deal”

    Consul

    • for service discovery and configuration management
    • Consul agent – does health check and forwards queries. Runs on machine of all apps
    • Consul server – elects a leader. Want 3-5 per data center. Must have at least 3 so can elect leader
    • Has UI – can see properties/services/etc. Can update config in UI in addition to through yml files [talked about risk of having the real properties be out of sync of the yaml. Good that devops has evolved to the point this is a common worry]
    • Same executable for server and agent

    Monitoring
    “health of the service is more important than the health of a single instance”
    Don’t need a page/alert if enough are still up

    Code>

    • Use spring-cloud-starter-consul-all Maven dependency – made by an independent company
    • Have dev mode so can run in isolation but test all the features
    • annotation to enable discovery
    • Have bootstrap.yml file to set up config – instead of application.yml

    thinks there is plugins/script to link version control to properties. good if need different properties in different environments

    I learned enough about Spring Boot yesterday to be able to follow Mike’s example. Seeing the live demo of Consol was nice.