This presentation covers some aspects of migrating of a monolithic application to Microservices architectural style.

1. Migrate to Microservices
Judiciously!
Petru Flueras
Software Architect - Visma Software
@pflueras
Codecamp Timisoara, Oct. 2017

3. About Me
● C# software engineer
● Software engineer and software architect at Océ Software
○ Huge (monolith) product ~ 1M+ LOC
● Software architect at Visma Software
○ Microservice (AWS)
● Timisoara Java User Group
● @pflueras

4. Why about Migration?
80% lifecycle of software = maintenance!
We have to evolve, modernize, adapt, … software repeatedly to context changes!
Recipes for building new software may not apply

5. Definition
Microservices architectural style:
… a single application as a suite of small services
… communicating with lightweight mechanisms
… built around business capabilities (SRP)
… independently deployable, upgradeable, replaceable!
… minimum centralized management of services
Decomposition + Distributed
Network calls (HTTP) + API
Again decomposition + API
CI/CD
Decentralized, dump pipes
Source: https://martinfowler.com/articles/microservices.html

6. Why about Microservices?
● Builds, broken builds, integration day(s)
○ Days/weeks to fix blocking point bugs
● We could not simply add new functionality (OutOfMemory)!
○ Single point of failure
● Highly coupled components (no clear interfaces/API)
○ Almost all classes are public
● Difficult to run system tests
○ Only at UI level (not at API level)
● Took ages to deliver business value
○ Continuous delivery
● Risk management

7. Frontend migration
Application decomposition
Database migration

8. Decomposition - Parnas
On the Criteria To Be Used in Decomposing Systems into Modules (1972):
"We have tried to demonstrate by these examples that it is almost always incorrect to
begin the decomposition of a system into modules on the basis of a flowchart. We
propose instead that one begins with a list of difficult design decisions or design
decisions which are likely to change. Each module is then designed to hide such a
decision from the others."
Source: https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

9. Decomposition - UNIX
UNIX Time-Sharing System: Forward (Douglas McIlroy - 1978):
● Make each program to do one thing well. To do a new job, build afresh rather
than complicate old programs by adding new “features”.
● Expect the output of every program to become the input to another, yet
unknown, program. Don’t clutter the output with extraneous information. Avoid
stringently columnar or binary input formats. Don’t insist on interactive input.
● Design and build software, even operating system, to be tried early, ideally within
weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
Source: https://archive.org/details/bstj57-6-1899

10. Decomposition - Domain Driven Design
● A way to mark boundaries and relationships between different domain models
● A BOUNDED CONTEXT defines the range of applicability of each model
● CONTEXT MAP gives a global overview of project’s contexts and relationships
between them
● Think about what is shared and what is hidden!
● BOUNDED CONTEXTS are good candidates for microservices
Source: Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans, 2003)

11. Decomposition - Transactions
● First decomposition should be around transactional context and not around
structure!
● Avoid distributed transactions as much as possible (2PC)
● Local transactions, eventually consistent (CAP)
○ Compensating transaction?

12. Decomposition - Strangler Pattern

13. Decomposition - Strangler Pattern #2

14. UI (Web) Migration/Integration
1. Gateway Aggregator 2. Links 3. Web Components

15. AWS - Links Example

16. Database Migration -> Decentralized, Schema Split
● Each service owns its data!
● The hardest part of microservices is data (C. Posta)
● Code is easy, state is hard (E. Yanaga)

17. Database Migration
● ACID vs BASE
○ Atomic, Consistent, Isolated, Durable
○ Basic Availability, Soft-state, Eventual Consistency
● Extremely difficult to split databases!
○ Even if splitting schemas works, moving data from one schema to splitted schemas is HARD!
● Handle inconsistent situations at code level (CAP)!
○ No foreign keys
○ No transactions

18. Distributed Systems - Network fallacies
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
Source: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

19. Distributed Systems - Design for failure
A distributed system is one in which the failure of a computer you didn't even know
existed can render your own computer unusable - L. Lamport, May 1987
● Netflix
○ Chaos Monkey: … randomly terminates one of the services/instances
○ Simian Army: … consists of services (Monkeys) in the cloud for generating various kinds of failures
○ FIT: … a platform that simplifies creation of failure within our ecosystem with a greater degree of
precision for what we fail and who we will impact
● Google
○ DiRT (Disaster Recovery Test): … where systems are taken down with little or no notice to verify
that all the failure protection systems work
=> Monitoring

20. Distributed Systems - Stability Patterns
Avoid (cascading) failures:
● Timeouts
● Circuit breakers
● Bulkheads
● Retry (Exponential back-off, Idempotent!)
● Throttling

21. Deployment
● Build Pipelines and Continuous Delivery
○ Any commit represents a potential release
● Infrastructure automation!!!
○ Immutable infrastructure
○ Infrastructure as Code
○ Ansible, Terraform
At Visma: AWS test env. -> AWS staging env. ->AWS production env.

22. Team and Organization
● “Microservices” is a organizational change!
● Independent (decentralized) teams who fully own their services:
○ Requirements/Specifications
○ Source code
○ Quality
○ Deployment
○ Technology selection ?!
● Cross functional teams
Conway’s Law (1967)

23. Security
● Service to service Authorization and Authentication (service accounts?)
○ Allow? operations (inside) to an internal service
● Single Sign-On
○ SAML
○ OAuth2, Open ID
○ LDAP
● Client-side certificates
● API Keys
Considerable increase of surface attacks!

24. Logging
● Push logs outside service!
● Correlation IDs
● Log Aggregation (Logstash, Fluentd, Kibana, ...)
● Standardize log message format
AWS CloudWatch

25. Monitoring
● Inside services
○ Memory usage
○ CPU usage
○ SQL queries per minute
● Incoming to service
○ Request rate (# requests per second)
○ Error rate
○ Service latency
● Health checks (service itself + downstream services)
● Implement Alerts!
AWS CloudWatch, AppDynamics, OpsGenie

26. Monolith Microservices
Business Agility Low High
Team technical knowledge Good Higher
Complexity High (coupled dependencies!) Reasonable
Scalability Vertical Horizontal
API Poor quality, optional? Good if done right, mandatory
Frontend (UI) Complexity Medium Higher
Deployment Manual? - Entire application CD - by service
Logging In one place (good) Distributed
Monitoring Not necessary: all or nothing Distributed systems => Necessary!
End to end testing Relatively easy Complicated
DevOps Complicated Easy

27. Takeaway
Microservices:
Small autonomous services which work
together, modelled around a business
domain
Sometimes the necessary step!
Add a lot of complexity!