Foreword
Jung-heon Han, he became disillusioned with the outsourced developer environment, where he felt like a conveyor belt worker.
At first, he enjoyed coding because he felt like he was creating something.
But then I became an unenjoyable developer who was forced to meet deadlines and implement features.
He became an expert in development methodologies and tried to apply CBD, MDD, and other techniques, but experienced many failures.
What is good software?
It needs to support rapid business change, but it also needs to be flexible and agile in design and process so that the developers who create it don’t have to suffer the same fate.
First, we tried to improve our code by writing test code and continuous integration.
Second, we thought that paying attention to design quality would follow naturally.
Then, as MSA in the cloud became a trend, the focus on design quality came naturally.
In the end, this book is for beginners who are familiar with the outsourced development scene but want to get into MSA development.
Chapter 1: Secrets of Amazon Business Agility
Companies like AWS, Uber, Netflix, and others that dominate one industry of business today have one thing in common: agility.
so that’s agility.
To give you a real-world example,
Amazon’s shopping mall goes live in less than a second, whereas a typical project takes weeks to months to plan, design, develop, and deploy.
Amazon’s mall is deployed 1.5 times per second (compared to 1 every 0.66 seconds)
If you look at e-commerce shopping malls in my country, the average is about once a week or once every three days.
The difference can also be seen as follows
— Stores that update once every 3 days (11th, auction, etc.)
— Stores that update once every 0.66 seconds (Amazon)
The store that updates once every 0.66 seconds, which is very reasonable, should have the edge.
In other words, Amazon feels like a living, breathing, cellular entity.
This is the difference in business agility.
1. Cloud infrastructure
Configuring infrastructure in an on-premises environment can be so time-consuming that there are teams dedicated to it.
But with the evolution of cloud infrastructure, you can configure your infrastructure with just a few clicks.
Many fresh startups can create services in minutes like the one above, allowing them to be nimble and agile in their business development.
But as usage grows, shouldn’t you be able to increase the performance of your devices, or increase the number of devices? We call this scale-up and scale-out.
Scale-up is a vertical expansion, where you increase the specs of your device.
Scale-out is a horizontal expansion, where you increase the number of devices.
For example, to prepare for the influx of traffic during a time sale, a system operator might plan for the following operational scenarios
- increase the capacity of the time sale service module
- replicate Time Sale service instances as traffic increases
- scale up & replicate to appropriate capacity through hands-on & clinical testing
This is the difference between monoliths and microservices. In a monolith system, the entire monolith scales when you replicate an instance.
However, in a microservice system, only the specific service that is experiencing heavy traffic is scaled up.
From this point of view, the disadvantages of monolith systems are maximized.
On the other hand, each service module can be developed in a different language.
Each service and repository can be isolated from other services and repositories and can be deployed independently.
Polyglot: This autonomy of the language used to build a particular service is called a polyglot.
What are the conditions for microservices? Conway’s Law, defined by Melvin Conway, defines the relationship between an organization and the SW it develops.
It states that each team is created for the same technology, e.g., a UI, server, and database are needed to create an application.
- UI team
- Server team
- DB team
Therefore, communication between the three teams is necessary.
This team structure increases the cost of communication between teams and delays decision-making.
So, how should a microservices team be structured?
- It should be functionally centered.
Functional teams are composed of different roles that can perform a service from start to finish.
This is because they have all the necessary skills and capabilities to create a microservice,
they are loosely coupled with microservices created by other teams.
Within Amazon, these teams are sometimes referred to as cross-functional teams because of their cross-functional nature.
Cross-functional teams are responsible for both development and operations.
Organizations that create microservices like this do not seek strong central governance. They don’t enforce adherence to strong central standards or procedures.
To draw a real-world analogy, the United States might be organized similarly to the various states in the country.
Each team finds and applies its own efficient methodologies, tools, and technologies.
- Product teams choose NoSQL and Node.js for fast search.
- The contract team chooses Java, Oracle, and Redis for contract services.
This process of each service team choosing the right language and repository for their team is called Polyglot Programming and Polyglot Persistence.
Changing the development lifecycle: product-centric, not project-centric Most traditional development methodologies are project-based, meaning there is a separation between development and operations.
However, microservices development methodology adopts product-centric agile development methodology to flexibly respond to changes.
It is developed and deployed in sprints of about two to four weeks to allow for refinement.
This approach treats the product as something to be continuously improved and evolved, rather than something to be delivered to the operations organization once the functionality is satisfied.
Changing the DevOps landscape: Automating infrastructure Automating CI/CD is a big part of leveraging cloud infrastructure and speeding up development. In large organizations, the number of microservices is growing rapidly, which is why Infrastructure as Code (IaC) approaches are gaining traction — treating them as if they were software. Think Teraform, etc.
Storage is changing: decentralized data management instead of federated storage While the trend used to be toward normalization to keep data organized, storage is now so cheap that there’s no need to cram each store into a small space.
Microservices opt for a polyglot storage approach, where they can’t directly call other services’ stores, but only access them via APIs.
However, this structure complicates business processing.
There is the issue of data consistency in each microservice’s repository.
To handle data consistency, we usually use distributed transaction techniques such as two-phase commit. This is sometimes referred to as Eventual Consistency.
Compensating transactions can be achieved with a queuing mechanism as shown below.
Ex) Order processing and order cancellation process
- order processing
- Order event occurs
- Send order event to Queue
- Read order event from delivery service
- shipping processing
- shipping fulfillment failure
- Send a failed shipment fulfillment event to Queue
- Read the failed shipment event from the order service
- cancel order (compensation transaction)
— Changing the way we respond to crises: designing for failure Werner Vogels,
a vice president at Amazon, once said,
All software fails.
Traditional system architectures strive for faultlessness or fail-safe integrity.
But it’s easier and more efficient to create a system that can respond quickly to failure than to create a system that never fails.
An example is the circuit breaker pattern.
It monitors services, and when one goes down or fails,
it disconnects the services that call it and allows them to respond appropriately.
Netflix even created a tool called “Chaos Monkey” to intentionally cause failures to check that this elastic architecture is working properly.