SkopjeTechMeetup is an initiative by Tricode for supporting and strengthening the Macedonian IT community. The meetups have the goal of establishing a networking platform for the IT crowd where they can share their know-how, best practices, as well as mutual inspiration. The 6th STM installment took place at Piazza Liberta, Skopje last Thursday, the 29th of September. This meetup hosted 3 seasoned speakers, each accomplished in their own way. Here's the presentation of Lazo Apostolovski. The Microservices Architecture pattern is getting a lot of attention lately, even at the beginning of its adoption lifecycle. It has significant benefits when it comes to enabling agile development and delivering complex enterprise applications. Adopting Microservices can be a tricky and dangerous process. Making bad decisions early can lead to serious complications, expences and maybe even failure.

1. Monolithic to Microservices
Architecture
LAZO APOSTOLOVSKI
JAVA DEVELOPER @ TRICODE MACEDONIA

2. What is Monolithic Architecture?

3. Monolithic Architecture drawbacks?
● Huge code base
● Hard to manage
● Difficult Continuous Integration
● Difficult application Scaling
● And so on...

4. What are Microservices?

5. What are Microservices?
Microservices are
small,
focused,
autonomous
services that work together.

6. Benefits of Microservices
● Mixed Technology can be used
● That fits needs of that microservice.
● Resilience
● If one node fails, others continue to work and isolate the problem.
● Ease of Deployment
● On code change, only affected part can be redeployed faster.
● Composability
● Microservice can be used for different purposes, and from different applications.
● Replaceable
● Easier to replace, delete or rewrite is much easier on small functionality.

7. What Makes a Good Service?
3 things

8. What Makes a Good Service?
● Loose Coupling
● Whole point is to make changes to one service and deploy it.
● High Cohesion
● Related behavior is located on one place.
● Shared and hidden models
● Share only minimum information to customer, and hide internal
implementation.

9. From where to start?

10. Always start from
Monolith Application
and
split later.

11. Splitting the Monolith

12. Why to split the monolith?

13. Why to split the monolith?
● Code base is huge to manage
● Some part will change frequently
● We need to deploy new changes fast
● Some data need additional protection around
● Different technology should be used

14. Splitting is complex and will cost you a lot,
if you not do it right.

15. Where to start?
● From existing monolith
● Detect functionality boundaries
● Separate to modules first
● Extract as stand alone microservices

16. That is about code.
But what about database?

17. Splitting database
● Isolate data in separate tables first
● Break foreign key relations
● If all good move it to another database
● Extract code in microservice
● If fail merge it all back and rethink

18. Deal with...
● Static data (enumerations)
Copy or put it in configuration
● Shared data (different functionality use same data)
Can be separated as different microservice too
● Transactions (no transactions anymore)
Different ways to handle this. Try again later or abort everything.

19. T E S T I N G
Tests are important

20. TESTING
● Unit tests
Have a lot of them
● Acceptance tests
Check if its implemented like it should
● Performance tests
How system can handle the load
● Exploration tests
Finding the way to break the system

21. TESTING
● Service tests
Stub and mock external services
● Test service in isolation
● Test without user interface
● End-to-end tests
Testing all together
● Slow and tricky to manage
● Its hard to locate the problem

22. Developer's team write
tests by itself!

23. Testing microservice into production.
How to do it?

24. In production
all that go wrong
will go wrong.
Minimize the impact
with 2 basic approaches.

25. Minimize the impact
Blue / Green deployment.

26. Minimize the impact
Canary deployment

27. Microservices integration
Get it wrong, and disaster awaits.

28. Integration
tips.

29. Integration
Avoid braking changes!
Consumers should be able to use service until they are ready to switch.

30. Versioning
● Microservices are changing constantly
● Internal changes do not affect consumers.
● Changes should not prevent consumers use
service.
● Small changes and Breaking changes.

31. Dealing with small changes.
● New field is added
● Unused field is removed
● Consumer read only what is needed
● Use flexible technology JSON or XML.

32. Dealing with breaking changes
● Need to be avoided
● Support old version for a while
– Give consumers time to switch
● Two parallel service instance (easy way)
– Balance between them
● Expose both version under same instance
– Adding complexity need to be avoided

33. Integration
Make service simple for Consumers
Use common communication protocol. Json for example.

34. Integration
Hide internal implementation details
Consumers should not know what is happening inside microservice.

35. Integration
The Shared database

36. Integration
Interface the customer instead
Consumers should not know what is happening inside microservice.

37. Orchestration
and
Choreography

38. Orchestration and Choreography
● For example
When some event happen we need to:
1) Send confirmation email
2) Send order from warehouse
3) Update finance department
● This can be done on two ways.

39. Orchestration
● Synchronous tasks execution
● One microservice delegate execution
● If “mastermind” service fails, all process stops
● Its slow
● Easier to guarantee consistency

40. Choreography
● Asynchronous tasks execution
● Every microservice is responsible for his job
● Its faster because all executions are parallel
● If some microservice fails others will complete
● Additional retry mechanisms

41. Microservices monitoring
Why we need it?

42. Microservices monitoring
● Single service, Single Server
Nagios is your friend

43. Microservices monitoring
● Single service, Multiple Servers
Nagios + Logstash for logs aggregation

44. Microservices monitoring
● Multiple services, Multiple Servers
Nagios + Logstash + Kibana for visual monitoring

45. Metrics can help a lot
● What hardware we need
How much resources we need for one service instance to run
● Do we need new host
If old one cannot provide us with enough power
● When we need to scale
Scale only in peak times
● How much we need to scale
Scale just enough to serve clients

46. Tools
● Graphite, Kibana, Varnish

47. System security

48. SSO (Single-Sign-On)

49. Service to service Authentication
● Allow everything inside perimeter
If attacker penetrate the security, all services are vulnerable
● HTTP(S) basic protocol between services.
Communication between services also need to be secured.
● Client certificates
Hard to manage, good data encryption
● API Keys
Shared public key between
● HMAC
Guaranties integrity of request

50. Database protection
● Encrypt database data
Encrypted data is useless for attacker
● Some database offer integrated encryption
Encrypt sensitive data in database
● AES, DSC
Good algorithms to use

51. Other protection inside perimeter
● Firewall
Block suspicious requests
● Intrusion detection
Monitor for suspicious activity
● Network segregation
Separate sensitive data in separate network
● Operating system
Apply security Patch regularly

53. This topic is huge,
but this is all for now.
Any questions?