Slide 1

Slide 1 text

Otavio Santana @otaviojava Mastering Microservices A guide to preventing chaos in your Java architecture member of KI group

Slide 2

Slide 2 text

Otavio Santana @otaviojava Staff Engineer ● Java Champion ● JCP-EC-EG-EGL ● Apache Committer ● Eclipse Committer ● Eclipse Project Leader ● Book and blog writer Speaker

Slide 3

Slide 3 text

Monolith

Slide 4

Slide 4 text

● Simple ● Easy to maintain ● Single application ● Less Operation complexity Monolith

Slide 5

Slide 5 text

“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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

● Conway's law ● Two-Pizza Team Rule ● Deploy Process Team

Slide 9

Slide 9 text

● More complex ● Operations complexity ● SAGA ● Minimum requirement Microservices

Slide 10

Slide 10 text

“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

Slide 11

Slide 11 text

“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

Slide 12

Slide 12 text

Old but gold

Slide 13

Slide 13 text

“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

Slide 14

Slide 14 text

API

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

API design + API + Contract First + Contract Last 1 of 10

Slide 17

Slide 17 text

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)

Slide 18

Slide 18 text

Documentation + Swagger + Language Documentation + Open-API 3 of 10

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

DDD + Ubiquitous Language + Domain + Subdomain + Bounded Context 5 of 10

Slide 21

Slide 21 text

Clean architecture 6 of 10 SOLID Layers + Presentation Layer ○ Controller + Application Layer ○ Service Orchestrating + Domain Layer ○ DTO/POJO ○ Entities ○ Services + Infrastructure Layer ○ Repositories ○ Config

Slide 22

Slide 22 text

Database + NoSQL vs SQL + Encapsulation + CAP 7 of 10

Slide 23

Slide 23 text

CQRS Command Query Responsibility Segregation + Greg Young's 2010 essay + Write - Command + Read - Query 8 of 10

Slide 24

Slide 24 text

Pagination + Performance + HATEOAS 9 of 10

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Xgeeks

Slide 27

Slide 27 text

xgeeks is changing the game in making things happen – giving on-demand capacity and bringing expertise filling skill gaps

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Thank you Otávio Santana Staff Engineer, Xgeeks @otaviojava Join us!! http://xgeeks.io/ @xgeeksio