The document discusses the challenges and risks associated with adopting microservices in software development, highlighting issues such as training requirements, operational complexity, and implementation mistakes. It emphasizes the need for careful consideration of organizational changes, operational standards, and non-functional requirements to avoid pitfalls. The author suggests seeking external guidance and prioritizing simplicity while navigating the complexities of microservices.

1. OptionFactory
Surviving Microservices
Challenges and risks during adoption, and what to look for beyond

2. Francesco Degrassi
Enthusiastic yet pragmatic Lean Software Developer.
Uppish and cynical nihilist from time to time.

3. OptionFactory
■ Lean Software Development
● Continuous Delivery - High availability - Scale-up
● Security sensitive & high uncertainty domains
■ Software Architecture Consultancy
● Technical Due Diligence

4. So you adopted microservices...
● After several years, microservices have gone mainstream now
● All adopters are paying the price in terms of
○ training requirements
○ solution complexity
○ operational costs
● Few are reaping the promised benefits

5. What are the pain points?
Implementing new
features takes
forever…
Lower velocity
We’re receiving a lot
of complaints for lost
documents
High defects rate
The import process
takes hours!
Performance issues
It is really hard to
understand what is
going on.
Lack of visibility
Lack of benefits Side effects

6. What are microservices anyway?
“[...] an approach to developing a single application as a suite of small services, each running in
its own process and communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently deployable by fully
automated deployment machinery. There is a bare minimum of centralized management of
these services, which may be written in different programming languages and use different data
storage technologies.
-- James Lewis and Martin Fowler (2014)

7. What are microservices anyway?
● Modeling
○ Components organized around Business Capabilities
○ Evolutionary Design
● Organization
○ Products not Projects
○ Infrastructure Automation
● Technical
○ Componentization via Services
○ Smart endpoints and dumb pipes
○ Decentralized Governance
○ Decentralized Data Management
○ Design for failure

8. What is the trade-off?
How microservices should help:
● Enabling Technology diversity (adopt
the best tool for each job)
● Independent component scaling
● Enforced module boundaries
● Scale-up development by decoupling
teams
The price:
● Managing all the technology diversity
● Distribution: new failure modes require
handling
● Eventual consistency
● Operational Complexity
● High training requirements
● High impact of design mistakes
(becoming architectural ones)

9. First issue:
(Lack of) Solution fit

10. (Lack of) solution fit (1)
Most organizations don’t have such
simple business logic,
huge scalability requirements,
risk appetite
of Netflix, Twitter, Instagram.

11. (Lack of) solution fit (2)
Netflix (Most of) us Microservices impact
Number & complexity of operations Few, simple Many, complex
Emerging requirements harder to accomodate, hard to
model, refactoring difficult
Coupling of components Low High
Complexity moved in inter-service communication,
which is the hardest to monitor and inspect
Concurrent users Millions Hundreds / Thousands Unnecessary complexity
Need to scale individual components
Definitely, e.g. transcoding,
streaming vs browsing catalog,
subscription
Possibly (needs hard data) Unnecessary complexity
Teams, developers Tens, hundreds Few, dozens No advantages
Ops resources Abundant Low to average Inability to cope with increased complexity
Team skill and training budget Very high Average
Risk of implementation mistakes, inability to spot
potential issues timely
Risk appetite
Higher (seeks technical competitive
advantage)
Lower Higher risk

12. Second issue:
Implementation mistakes

13. ● Failure to address organizational
change
○ Ops and security requirements
not considered in development
○ Lack of visibility of ops team on
mapping of business processes
over the entire platform
Implementation mistakes (1)

14. ● Modularization:
○ services should map to bounded contexts, but often are too fine-grained
○ services should expose transactional business operations
● API granularity: network calls are expensive; too fine-grained APIs are unsustainable
○ wrong perception of remoting cost, possibly due to it not being hidden by middleware
○ mistakes in modularization can make services too interdependent
○ failure to adapt when splitting a service out
Implementation mistakes (2)

15. ● Encapsulation: data should only be exposed through the service API
○ databases shared by multiple services are a huge red flag
● Coupling: services, in general, should not share code with one another
○ deployment independendence depends on it
○ shared model libraries are a common mistake, indicative of an erroneous
interpretation of microservices
● Complexity moving into interactions:
○ implicit state in asynchronous messaging
○ hardest thing to inspect and monitor
Implementation mistakes (3)

16. Third issue:
Failure to address impact on NFRs

17. ● Operability
○ Monitoring infrastructure
○ Infrastructure and configuration management
○ Deployment automation
○ Service Discovery
○ Tracing of calls through multiple systems
○ Logging context and centralized infrastructure
Failure to address impact on NFRs

18. ● Correctness, Performance, Scalability:
○ Skillset, Training, on e.g.:
■ DDD
■ Distributed systems
■ CI / CD, infrastructure management
■ Tooling
○ Development environment
● Availability, Resilience, Integrability, Compatibility
○ API versioning
○ Cater for cascading failure scenarios
○ Compound availability
Failure to address impact on NFRs

19. ● Data integrity, Retention, Durability, Disaster recovery
○ Backups and restores of individual services
● Security
○ Authentication, Access control, Accounting throughout services
○ Integrity and confidentiality of data in transit
● Testability
○ Automation, Infrastructure provisioning
Failure to address impact on NFRs

20. Are there no alternatives?
Not at all.
Many tenets of microservices can be applied to any other architectures too:
● Teams and components organized around Business Capabilities is (uncommon) common
sense
● Evolutionary Design, Cross-functional teams are not specific of microservices at all
● Infrastructure Automation, CI & CD are useful even with a single deployable

21. A false dichotomy
Storefront
WebApp
Account
Service
Inventory
Service
Shipping
Service
Order
Service
UI
Business
logic
Data access
layer
Storefront
UI
Account
Service
Inventory
Service
Shipping
Service
Order
Service
Accounts
Orders
ShipmentsInventory

22. No exclusive deal here...
Benefit Microservices Alternative
Strong module boundaries Enforced by architecture (which is
hard to change by definition)
Responsibility of the team
(empowerment)
If you need to enforce compliance, you might not afford microservices.
Why would you think the same team that built the big ball of mud can design
a functional set of microservices?
Independent deployment and scaling Possible (but not guaranteed) Possible (opportunistic, by extracting
a service)
Technology diversity Unconstrained Constrained, but available
Scale up development by decoupling
teams
By service By component / library / service

23. What now?
● Seek external guidance
○ Assess the state of the project
○ Without preconception
○ Using hard data
● Plan for remediation
○ Addressing NFRs can make the situation manageable short-term
● Avoid sunken cost fallacy
○ Architectural changes, by definition, are hard and costly, but...
○ there is no better time to change course than right now

24. ● Strive for simplicity
○ What is the simplest thing that could possibly work?
○ Not “is it too complex?” but “is there an actual need for any added complexity?”
● Do not buy into the hype:
○ there’s always a trade-off, make sure it is known and explicit
○ validate one choice at a time
● Make sure agency comes with responsibility
○ beware seagull engineering and CV padding
What next time?

25. Human beings, who are almost unique in
having the ability to learn from the
experience of others, are also remarkable
for their apparent disinclination to do so.
Douglas Adams
“
”
I hope you found this useful

26. Get in touch
https://www.optionfactory.net

27. Thanks for your time!
@EdMcBane
fdegrassi@gmail.com
francesco.degrassi@optionfactory.net
http://www.optionfactory.net