Tag Archives: cloud

[2021 kcdc] Enterprise Cloud Patterns for Java Devs

Posted on by
Reply

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

[2021 kcdc] lessons learned from enterprise cloud securty programs

Posted on by
Reply

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

Speaker:Karl Ots

Twitter @karlgots

Book: Azure Security Handbook

————————-

Cloud Security

  • Need cloud native security – specific to cloud provider using
  • ”Cloud can be as safe or unsafe as what you did before”

Shared responsiblity

  • Customer responsiblity: data, endpoints
  • Shared responsiblity: identity, application, os/middleware, network
  • Cloud provider responsiblity: physical

Security Program

  • Need to balance speed/“shadow cloud” (someone signing up for their own cloud account) with existing security requirements/eisting EA, lack of security awareness
  • Phases – cloud straegy, governance model, security, guidelines (ex: implementation guidelines and refernee architecture)
  • Cloud security framework defines architecture, policies and controls to secure cloud envrionment
  • Don’t be a generic list of controls. Just be tailored. Doesn’t make sense to apply anything. Cloud security alliance has a list of about 200 sample controls. Don’t just go thru a list of controls in Excel.
  • Terraform (or other tools) typically built by subject matter experts. Ex: database expert writes terraform module for database security
  • Certified products/platform concept – if you use products/components/tools that are pre-approved, can get through security faster. Vetted already

Identity and Access Management (IAM)

  • Integrate with existing IAM processes
  • DevSecOps CI/CD deloys using Azure AD ideneity to application resources. Other identities to actuall run (but not deploy and change things).
  • Need to be able to provide the CI/CD credentials not available/used by others
  • Create a vending machine type system so have to request things. ex: give me a X. Makes automated to request things

Detection and Monitoring

  • Need to enforce logging across landing zone and anything deployed
  • Centralize logs.
  • Ok to have temporary copy as well to focus on new info. Also some alerts verbose and ony want to monior key ones
  • Can build custom alerts, but doesn’t scale. If 10K Azure resources all with own logs, can be unmanagable.
  • Integrate with your SIEM an SOC
  • Separate resource logs (ex: who accessed X) and application logs (what developers log)

Network security

  • Cross subscription, cross region and cross cloud
  • Traffic from platform and infrastructure as a service + app level
  • Can grant access through
    • RBAC in the subnet – fast to do, but dev has to do it
    • Pre-provisioned NICs – medium, thru centralized cloud operations
    • Outside Azure/cloud – slow, thru centralized ops

Supply chain

  • New attack with pre-provisioned agent https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-omi-azure

My take

I’ve learned/used AWS. The speaker is an Azure expert. He tried to make the presentation as cloud agnostic as possible. It was realy good for me to see how much is common across clould providers. It was goo to understand how things I’m doing fit into the bigger picture and something I wish we did differently

[2020 dev nexus] keynote – dueling banjos

Posted on by
Reply

Burr Sutter (RedHat) and Ray Tsang (Google)

Freddy and Nancy played guitar/banjo to start

For more, see table of contents

Live demos

  • Ray
    • demo Kubernettes on Google Cloud
    • spring boot
    • jib-maven-plugin (use container registry instead of dockerfile)
  • Burr
    • demo OpenShift (Kubernettes implementation) running on Amazon, Azure and Google
    • quarkus
    • graalvm
  • deployed each other’s containers into the other one’s cluster
  • showed traffic redirection between cloud providers fronted both with a load balancer
  • audience load balancer – Can play at kubejava.com during the demo. Stopped it from the back end; good way to get everyone to pay attention again
  • move between clouds. took amazon instance down. showed auto failover to one of the others when unpaused

My take

Fun start to the day. We had music (banjos), a golden switch, a game and a high energy cloud presentation. Well, Or maybe it was two presentations concurrently..