Last week, on October 27th, our team attended CodeCamp in Cluj-Napoca. While our Talent Acquisition consultants were networking and meeting some of the best software engineers from Cluj, our Java developer Tudor Pătruțiu dived deep into the conference agenda and listened to speakers from Microsoft, Xpirit, Nagarro-ATCS, etc.
In this post, we’d like to share Tudor’s takeaways from the event with a broader software engineering community.
Codecamp Cluj: Key Takeaways
1. Architectural Thinking: Mark Richards
Recommended book – Fundamentals of Software Architecture: An Engineering Approach (can be accessed here)
A: Why is architectural thinking important?
An example: full event payload vs only key based payload.
- loose or strict contract for payload (bandwidth issue)
- data integrity issues
- stamp coupling
Key based payload:
- better data consistency
- contract management
B. Architecture characteristics
- business stakeholder and user satisfaction management
- maintainability, testability, deployability
- merger and acquisitions: standards, adaptability, portability
C. Technical depth vs technical breadth
- maintain what you know
- focus on the stuff you know you don’t know
- start expanding technical breadth (e.g., Infoq, ThoughtWorks technology radar, DZone Refcardz)
- 20-minute rule: to develop your career, read an articles or scout for new technologies as a first thing in the morning
D. Analyzing trade-offs
Everything in Software Architecture is a trade-off. Analyze and understand the trade-offs.
- business drivers: time to market
- performance vs maintainability
- Tip: avoid over-evangelizing a given solution
- use Publisher and Subscriber instead of queues.
- service level objectives: proof that you meet the SLA’s
- which service calls were involved, were there exceptions
- X-Trace -> Zipkin -> OpenTracing-> —— Open Telemetry – data collection with OpenTelemetry: OTLP
- optmize the tracing strategy: SImpleSpanProccesor, BatchSpanProcessor, JaggerUI – to view traces
- add Jagger config in ConfigMap for Kubetctl
- attach images
3. Service contracts profitability in automotive: Claudio Ceccotti, Nagarro-ATCS
- 80% of machine learning is preparing/cleaning the data
4. Compliance and EU Data Boundary in Azure: Alexandra Ciortea, Microsoft
- Compliance: grouped by different dimensions in Azure: US Gov, Financial, Health etc.
- Shared responsibility model: the customer remains responsible for managing and configuring security
- MDC – Microsoft Defender for Clouds
- other cloud providers can be connected with MDC
- audit reports to offer the compliance results (e.g ISO standards) – SCC kegak transfer mechanism for personal data leaving EU
- data residency and data protection
5. Evolving your service landscape: Alex Thissen, Xpirit
- typical service landscape: UI -> services (orders, payments)
- simplified service landscape: consumers and providers
- reasons for change: more features, performance, different data in payloads,change OAuth2 to OpenIDConnect
- types of change: replace, side by side, hybrid but depends on breaking and non-breaking changes
- contracts: service, operations, message, data, fault
- contract compatibility: non-breaking changes (almost never): new endpoints,new methods
- reducing coupling and dependencies: reduce the number of contracts
- partition into domains (domain driven design/DDD): orders into ordering to avoid
- direct coupling
- indirection of communication: publisher-subscriber with a topic
- softening impact of changes: add a gateway for stabilizing contracts,protocol transition, offers shielding:
- api management
- backend for frontend
- composer or aggregator
- reverse proxy
- cloud patterns for handling transient faults: – retry
- circuit breaker
- bulkhead isolation
- implementing multiple versions:
- semantic versioning: 3.1.2-alpha1
- date-based: 18.04 -linux
- contract testing: https://pact.io
6. Designing in the world of Microservices: Venkat Subramanian, Agile Developer Inc.
What are the characteristics of good design?
- high cohesion: technology based cohesion vs domain based cohesion – loose and low coupling
What is a microservice?
- system of interconnected applications
- multiple units of deployment
- isolated deployment
- universal data model is a disaster in the making
- choose distributed data model with hidden details and shared details with sufficient mapping
- when you share a database you break encapsulation
Why build microservices?
- to deliver business agility
Don’t let current perception influence your design!