The Hype Microservices

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.

Why now?

• 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

Advantages

• 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

Drawbacks

• 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

Recipes

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 in-depth posts

• CICD
• Deployment
• Logging
• Monitoring
• Service Discovery
• Communication
• Load Balancing
• Persistence
• Security
• Testing

Takeaways

• 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

Conclusion

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.