Chapter 2. Microservices
In the last chapter, we talked about the pain of distributed systems. Microservices seek to ease that pain by providing a structure and set of best practices to make sure that the development of your application will scale. You may be thinking: why am I concerned with the scalability of the development of my project? Scalability has always been a pain point for applications and organizations that have the ambition or the need to grow past a single team of developers.
There are many definitions of microservices, but I think Sam Newman described them best in Building Microservices as “small, autonomous services that work together.” They are an evolution of service-oriented architecture (SOA) to fit the way organizations are actually structured. If a service can no longer be developed or maintained by a single team of developers, it is too big in the eyes of microservices. How big should that team be? That is up to your organizational structure.
In some ways, microservices are a bottom-up revolution in software engineering. They are a fight that was waged by the masses and have arrived at a critical mass of adoption. People joined this war for the increased autonomy of choosing their own implementation details and the decreased friction of developing tightly coupled systems, such as monoliths. While microservices are eating the world, that does not mean you will need them specifically. We will end this chapter with a look into the circumstances in which you ...
Get Learning Serverless now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
