December 12, 2018 • ☕️ 4 min read
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.
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
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.
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
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.
Startup Founder, Software Engineer Follow me on Twitter