Towards Modern Development of Cloud Applications
Link to Source: link
- {Date}
Quick Summary:
- Methodology: What was their experimental design? How did they induce their results?
- Findings: What did they expose with their research? What was surprising?
Takeaway:
- What is the relevance to our use case?
- What do they do that we should emulate?
Scratch Notes:
Abstract
They propose that instead of creating microservices based on logical boundaries (how code is written), it should instead be done with physical boundaries (how code is deployed)
They propose that applications should be written as logical monoliths, and then the decision of how to divide them should be made at runtime.
Intro
Reasons behind splitting boundaries:
- Improves performance, allows binaries to be scaled independently
- Improves fault tolerance, a crash in one microservice doesnt impact others
- Improves abstraction boundaries, microservices create clear APIs and communication. Code entanglement minimized
- Improves rollouts, deployments at different rates
Challenges
Challenges with micro:
- Hurts performance, sending data over network is a bottleneck
- Hurts correctness:
- Difficult to reason about every possible interaction, especially with version control
- Case study of 100 catastrophic failures found 2/3s were caused by interactions between multiple versions of a system
- Hard to manage, devs have to do devops for
binaries - Freezes APIs, hard to update without breaking consumers
- Slows down development. When making changes that affect multiple microservices, developers cannot implement and deploy the changes atomically. Must be concerned with how to ‘rollout’ and ‘schedule’ the changes across all deployments
Devs current accept those challenges as price of doing business. Software exists to ease some of the challenges:
- CI/CD - allows code to be pushed to prod faster (this can be its own issue)
- Programming libs make it easier to create/discover network endpoints, but dont address application management
- Network protocols - gRPC and Protocol Buffers are continuously improved, but are still a major bottleneck
Proposed Solution
Write a monolith, and have a runtime divide it up (autowiring it)
- Allows for seperation/decoupling of logical and physical boundaries
- Logical - Code can still be modularized as needed
- Physical - Decided at runtime, not based on logical boundaries
- Allows for easier reasoning about correctness, the entire monolith is deployed and acts on the same version
- Easier management
❓-> Questions during reading
🧪 -> Refresh the Info
Did you generally find the overall content understandable or compelling or relevant or not, and why, or which aspects of the reading were most novel or challenging for you and which aspects were most familiar or straightforward?)
Did a specific aspect of the reading raise questions for you or relate to other ideas and findings you’ve encountered, or are there other related issues you wish had been covered?)