Over the last 9 months, I have invested most of my time developing a real estate social networking site which using Microservices architecture. After much reading, note taking, white-boarding, and many hours coding, I feel like I have achieved a level of understanding such that I am ready to take the first step. Allow me to share what I have learned about this.
No country for old men
Back in the olden days, applications were built monolithically. The application likely consisted of the web server itself and perhaps some kind of data storage system and were just built and packaged into one or two binaries. These binaries were then uploaded to a server rack and run directly on the machine. This was fine for the internet of the 80s and the 90s
With monolithic architectures, all processes are tightly coupled and run as a single service. This means that if one process of the application experiences a spike in demand, the entire architecture must be scaled. Adding or improving a monolithic application’s features becomes more complex as the code base grows. This complexity limits experimentation and makes it difficult to implement new ideas. Monolithic architectures add risk for application availability because many dependent and tightly coupled processes increase the impact of a single process failure
The hype microservices
Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.
- The first steps to reduce cost of delivery focused on process automation
- The DevOps movement on the wave of AWS and GCP
- The age of containers
- Advances in CPU and network technology
- Advances in storage & database technology
- Agility: independent teams that take ownership of their service
- Flexible Scaling: independently scaled to meet demand for the application feature it supports
- Easy Deployment: enable continuous integration and continuous delivery
- Technological Freedom: choose the best tool for each job
- Reusable Code: a service written for a certain function can be used as a building block for another feature
- Resilience: service independence increases an application’s resistance to failure
- Additional complexity of creating a distributed system.
- Testing is more difficult
- Inter-service communication mechanism.
- Using distributed transactions is difficult
- Requires careful coordination between the teams
- Deployment complexity
- Increased memory consumption
When you start looking into Microservices, you enter a rabbit hole that’s absolutely massive. It makes Alice in Wonderland seem like a piercing. You quickly learn that you will need to manage all of these microservices and balance the load whilst monitoring everything that is happening. Oh, don’t forget that you’re going to need to care following topics which I strongly believe deserve another indepth posts
- Service Discovery
- Load Balancing
- Microservices are a business solution, not just a technology solution
- Treating microservices as splitting code layers into docker-ized boxes can lead to “death by a thousand cuts.”
- You don’t need microservices to run multiple instances of a service or worker. Good monoliths can also scale for some classes of problems
- Microservices are a culmination of multiple engineering practices. They have a steep curve of learning, unlearning, and transformation
Before, people used to have this one application, that some parts of it were complex, and now this complexity is all over the system in different services and distributed between multiple services
One challenge is deciding when it makes sense to use it. When developing the first version of an application, you often do not have the problems that this approach solves. Moreover, using an elaborate, distributed architecture will slow down development. This can be a major problem for startups whose biggest challenge is often how to rapidly evolve the business model and accompanying application
In my opinion sooner or later you'll use microservice architecture, the point is how much complexity you want to implement and when to implement.
- Pattern: Microservice Architecture
- Testing Microservices, the sane way
- Microservices are hard — an invaluable guide to microservices
- Understanding Microservices: From Idea To Starting Line
- REST in Peace: Microservices vs monoliths in real-life examples
- How to scale Microservices with Message Queues, Spring Boot, and Kubernetes
- Evolution of business logic from monoliths through microservices, to functions
- A Microservices implementation journey
- How Teams Get Microservices Wrong From the Start
- What is Microservices Architecture?
- Introduction to Microservices
- Build highly available microservices to power applications of any size and scale
- Goodbye Microservices: From 100s of problem children to 1 superstar
- How Microservices Saved the Internet