Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Survival Guide for the Java Architect in the Cloud Era

Survival Guide for the Java Architect in the Cloud Era

Let's be very honest, cloud computing cannot be learned in one day. There are several architectural challenges to deploying your application, such as which framework to choose, reflection or reflectionless, native or non-native. We also have operational challenges such as backups, CI/CD, and much more. This presentation explains how to make some of these design choices and the tradeoffs to consider when building applications to run in a virtual cloud environment.


Otavio Santana

March 29, 2021

More Decks by Otavio Santana

Other Decks in Technology


  1. Otavio Santana @otaviojava Mastering Microservices A guide to preventing chaos

    in your Java architecture member of KI group
  2. Otavio Santana @otaviojava Staff Engineer • Java Champion • JCP-EC-EG-EGL

    • Apache Committer • Eclipse Committer • Eclipse Project Leader • Book and blog writer Speaker
  3. Monolith

  4. • Simple • Easy to maintain • Single application •

    Less Operation complexity Monolith
  5. “Given the importance of defining stable service boundaries, I feel

    that microservice architectures are often a bad choice for brand new products or startups” Should I use microservices? By Sam Newman A good start Database Business Logic
  6. Deprecated? “Leadership set the direction of microservices without consideration for

    the challenges and state of our application. After evaluating it, we found that microservices weren’t a fit for us, and required significant compromises.” Why our team cancelled our move to microservices By Steve Lemon
  7. Don’t follow the herd “Certainly, we always read great things

    about the microservices architectures implemented by companies like Netflix or Amazon. So let me ask a question: how many companies in the world can be Netflix and Amazon?” Migrating to Microservices Databases By Edson Yanaga
  8. • Conway's law • Two-Pizza Team Rule • Deploy Process

  9. • More complex • Operations complexity • SAGA • Minimum

    requirement Microservices
  10. “Microservices introduce eventual consistency issues because of their laudable insistence

    on decentralized data management. With a monolith, you can update a bunch of things together in a single transaction. Microservices require multiple resources to update, and distributed transactions are frowned on (for good reason). So now, developers need to be aware of consistency issues, and figure out how to detect when things are out of sync before doing anything the code will regret.” Microservice By Martin Fowler Complexity
  11. “We also address the critically important issue of trade-off analysis.

    As a software developer, it's easy to become enamored with a particular technology or approach. But architects must always soberly assess the good, bad, and ugly of every choice, and virtually nothing in the real world offers a convenient binary choice - everything is a trade-off.” Everything is a trade-off
  12. Old but gold

  13. “Microservices are independently deployable services modeled around a business domain.

    They communicate with each other via networks, and as an architecture choice offer many options for solving the problems you may face.” Moving to Microservices
  14. API

  15. 1. API Design 2. Glory of Rest 3. Documentation 4.

    Versioning 5. DDD 6. Clean Architecture 7. Database 8. CQRS 9. Pagination 10. Security The 10 commandments Roan Brasil @roanbrasil
  16. API design + API + Contract First + Contract Last

    1 of 10
  17. Glory of Rest 2 of 10 + Level 0 ◦

    HTTP - transport system for remote interactions + Level 1 ◦ Individual resources + Level 2 ◦ POST ◦ GET ◦ DELETE ◦ PATCH/PUT + Level 3 ◦ HATEOAS (Hypertext As The Engine Of Application State)
  18. Documentation + Swagger + Language Documentation + Open-API 3 of

  19. Versioning 4 of 10 + URL ◦ http://yourapi.domain.com/api/v1/doSomething + Query

    Parameters ◦ http://yourapi.domain.com/api/doSomething?version=1 + Custom Headers ◦ Accept-version: v1 + Content Negotiation ◦ Accept: application/vnd.domain.v1+json ◦ Accept: application/vnd.domain+json;version=1.0
  20. DDD + Ubiquitous Language + Domain + Subdomain + Bounded

    Context 5 of 10
  21. Clean architecture 6 of 10 SOLID Layers + Presentation Layer

    ◦ Controller + Application Layer ◦ Service Orchestrating + Domain Layer ◦ DTO/POJO ◦ Entities ◦ Services + Infrastructure Layer ◦ Repositories ◦ Config
  22. Database + NoSQL vs SQL + Encapsulation + CAP 7

    of 10
  23. CQRS Command Query Responsibility Segregation + Greg Young's 2010 essay

    + Write - Command + Read - Query 8 of 10
  24. Pagination + Performance + HATEOAS 9 of 10

  25. Security Basic Authentication OAuth 2.0 + JWT - JSON Web

    Tokens (RFC 7519) ◦ JWS - JSON Web Signature (RFC 7515) ◦ JWE - JSON Web Encryption (RFC 7516) Site: https://jwt.io/ 10 of 10
  26. Xgeeks

  27. xgeeks is changing the game in making things happen –

    giving on-demand capacity and bringing expertise filling skill gaps
  28. What makes us strong We are bringing passion and eXpertise

    into the team. High Coding standards Reliable and proven processes and quality testing Continuous Innovation Senior/Junior split 1:2 enables room for innovation Integration in KI group Strong backing and steady exchange with experts Flexible work style Individual and flexible, fully acustomed to our clients
  29. What makes us special Member of KI group – home

    of entrepreneurs, solvers & creators. © xgeeks | 02/12/2020 29 Software and data Human resources Business models, processes and company building Experiences, design & lifestyle Investments and ecosystems
  30. Thank you Otávio Santana Staff Engineer, Xgeeks @otaviojava Join us!!

    http://xgeeks.io/ @xgeeksio