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

Speaker: Pratik Patel (Azul)

Twitter @prpatel

————————-

Philosophy

• 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

URLs

https://docs.microsoft.com/en-us/azure/architecture/patterns/

https://aws.amazon.com/architecture/

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