[2021 kcdc] Enterprise Cloud Patterns for Java Devs

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker: Pratik Patel (Azul)

Twitter @prpatel



  • Monoliths are not elastic. Cloud is
  • Doesn’t waste money
  • Must design for elasticity
  • We learn to avoid premature optimization/keep it simple stupid. In the cloud, we have to do some optimization
  • Need to design for horizontal scaling (adding more servers/virtual servers)
  • Need entire architecture to be elastic. Else have created a bottleneck
  • Think about cosT, adapabiity/agil/security, time to market

Cloud native review

  • Containerized
  • Dynamically orchestrated (actively schedule containers to optimize resource utiilization)
  • Microservices oriented (try to avoid dependencies between microservices – not possible to avoid, but minimize)

Types of Patterns

  • Design and implementation – covered today
  • Performance and scalabity
  • Data management
  • Availability and reliabliliy

Ambassador Pattern

  • For transitioning legacy apps – could be monolith or SOAP or Java EE or Spring Boot or whatever to microservices
  • The Ambassador is a proxy. It adds monitoring, retry and a protocol adapter (hide SOAP/RMI from clients) and delegates to the legacy app.
  • This lets the callers all the Ambassador and get these cloud capabilities.
  • Implemented as a sidecar (does extra stuff)
  • Use Spring RestTemplate (now called WebClient) or Microprofile Rest client 2.0
  • For end user/callers

Anti-corruption pattern

  • Also for transitioning legacy apps
  • Callers is another service (microservice, cloud function, event driven api)
  • Does more than ambassador.
  • Facade/adapter pattern
  • Firewalls legacy apps
  • Useful for migrating large glegacy app
  • Protocol adapers
  • Legacy unchangeable APIs
  • Compartmentalize legacy app to protect requests coming in and rest of system in case something gos wrong
  • Spring Reg Template or Microprofile Rest client 2.0
  • Must define specific endpoints

Gateway aggregation pattern

  • For when app needs to call multiple services (ex: auth, media)
  • Calls multiple services and returns the results of multiple services to caller in one shot
  • Groups related services into one API call
  • Avoids death star anti-pattern when everything cals everything else
  • Client calls gateway not services directly
  • MUst think about how to handle failures in downstream services
  • Use SprIng AsyncRestTemplate (or web client) or GraphQL (Sprin, Microproile or SmallRye) – note that graphql introduces dependencies. Good to return a bunch of related data.

Back end for front end (BFF)

  • For flexibiity and performance
  • Adapter by client type (ex: mobile, web mobile, web desktop)
  • Returns data in way most practical and efficient for that client
  • Calls microservice and/or legacy app
  • Can be an implementation of a gateway aggregation pattern
  • Make sure not premature optimzation
  • Data can be shaped and size for specific needs
  • Improved performance
  • Could introduce code duplication
  • Are front and back end devs on same team.
  • Sprint AsyncRet Tmplate or Microprofile CompetableFuture or RestClientBuilder
  • Can be different URLs by service type – ex: mobile url (or header sniffing in API gateway)

Gateway Routing

  • Commonly used/misused
  • Calls proper service based on URL
  • Helps minimize change to clients
  • Reducing coupling directly to services
  • Tradeoffs: latency, bottleneck
  • Spring RestController or Microprofile JAXRS. Or cloud pattforms APAI gateway




My take

This was very fast moving, but I found it understandable. I learned a lot. I liked Pratik’s hand drawings of the patterns. It was also interesting that most people were using AWS at a primarily .NET conference

Leave a Reply

Your email address will not be published. Required fields are marked *