Tag Archives: microservices

[2022 javaone] foundations of modern java server apps

Posted on by
Reply

Speaker: Kito Mann

For more see the table of contents

Notes

  • In cloud, have both microservices and traditional web apps

Microservice

  • Container (ex: docker) including UNIX kernel
  • Executable Jar or Native Image (ex: Graal)
  • Example microservice framework – Http Server, Http Java Integration, REST processing, JSON serialization, JSON parsing, validation, security, database integration, dependency injection, messaging, mail, health checks, tracing, fault tolerance, metrics, config, OpenAPI docs, GraphQL
  • Microservice frameworks – Spring boot, quarkus, micronaut, open liberty

Spring Boot

  • Http Server – Jetty, Tomcat or Underflow
  • Http Java Integration – Jakarta Servlet
  • REST processing – Jakarta RESTful Web Services or Spring MVC
  • JSON serialization – Gson, Jackson or JSON Binding
  • JSON parsing – Gson, Jackson or JSON Parsing
  • validation – Jakarta Bean validation
  • security – Spring security
  • database integration – JPA and others
  • dependency injection – Spring framework
  • messaging – Jakarta messaging, kafka and others
  • mail – spring java mail sender or jarkarta mail
  • health checks – spring boot actuator
  • tracing – spring cloud sleuth
  • fault tolerance – spring cloud circuit breaker and spring cloud netflix
  • metrics – micrometer
  • config – spring boot config
  • OpenAPI docs – Spring REST data
  • GraphQL – Spring for GraphQL

Others

Did same for Quarkus, Payara Micro, Jarkarta EE. Didn’t transcribe deck

A lot of delegating to Jakarta and MicroProfile projects

MicroProfile

  • Started in 2016

Jakarta projects

  • Jakarta Interceptors – standard way of writing interceptors
  • Platform – Jakarta enterprise beans, authorization, batch, connectors, mail, activation, messaging, web profile, core profile
  • Optional (not fully supported) – Jakarta enterprise web services, xml binding, SOAP with attachments, XML web services
  • Web profile – servlet, bean validator, persistence, authentication, web socket, CDI, mail, security, transactions, expression language, managed beans, concurrency, faces, standard tag libraries, server pages, enterprise beans light
  • Core profile – interceptor, dependency injection, annotations
  • Required for MicroProfile – Jakarta RESTful web services, JSON processing, JSON binding, CDI light
  • CDI surpassing EJB
  • New: Jakarta RPC, NoSQL, data
  • Removed: Jakarta Management

Java EE Server

  • War
  • Jakarta Servlet, RESTful web services, JSON binding/parsing, bean validation, security, persistence, CDI, messaging, mail

My take

Wow. A lot has changed since I last worked on a web app. Learned a lot here although the talk was longer than my attention span; especially later in the day. It was a bit of an info dump but good for getting the lay of the land. And I need to do a lot of reading!

The Paved PaaS to Microservices – live blogging at qcon

Posted on by
Reply

The Paved PaaS to Microservices
Speaker: Yunong Xiao @yunongx
See the list of all blog posts from the conference

Yunong is from Netflix. Talked about how serving multiple types of devices. Can innovate faster if not worrying about infrastructure

Scale. 1K+ microservices. JavaScriptfront end; Java back end.

Client teams own microservices for front end/client devices. Edge API is server based/back end API

Standardized Components

  • Common set of components – ex: metrics, logging, alerts, dashboard, configuration
  • Don’t want everyone picking RPC mechanism. Invest in one set of tooling
  • Benefits of standardizing: consistency (ease of troubleshooting/support), leverage (more time for business problems with platform team focused on components), interoperability (easier integration so faster velocity and less cognitive overload), quality (more investment so higher chance of quality), support (greater knowledge base)
  • “But I’m a Snowflake” – Netflix has culture of freedcom and responsibility. Helps with innovation. If works, re-integrate into ecosystem. Be concious of talking to the others and the cost to other teams of your choice.

Pre-assembled platform

  • Starting a new project, there isn’t velocity yet nor stats on reliability.
  • Putting components into a pre-assembled platform so can just add business logic. Less likely to be missing things like metrics because in pre-assembled platform.
  • Guarantees standard and consistent metrics. Reducs MTTD (mean time to detect) and MTTR (mean time to recover)
  • Maintenance vs convenience – easier for platform team to include just basics. Easier for app team to have more included. The solution is layers and favors. Having a base platform and add ons.
  • Testing – running other team’s microservices tests when upgrading a platform tests the platform upgrade
  • Design for configuration and hooks
  • API Semantic versioning (like what Maven versions do)
  • Use conventional changelog to automatically creat changelog

Automation and Tooling

  • Provide CLI for common dev experience – allows scripting and consistent environment each time. Ensures can run locally and in the cloud
  • Local development fast – use local debugger and curl. Can still test with container so mirrors prod config
  • Provide first class mocks for components in pre-assembled platform. Facilitate determining where the problem lives. Easier to write reliable automated tests.
  • Provide facilitate to generate mock data
  • Need a testing API so different groups can work on mocks. Component teams create mocks against standard APIs
  • “Production is war” – different levels of experience in ops. Use tools to avoid shooting off own foot. Ex: pipelines for deployment/rollback, automated canary analysis
  • Dashboards provide a consolidated view for ops. Having platform generate dashboard and alerts standardizes them. Also allows for automate analytics and tooling.

Provided warning about not just copying Netflix. PaaS is for certain use cases. Components help regardless.

TDD for Microservices Architectures – live blogging from spring days

Posted on by
Reply

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!