Microservices are an architectural approach to software development based on building an application as a collection of small services. There is no standard definition for what amount of code constitutes a “small service.” But some experts say it’s about the size at which a team can query the service’s health with a single request that returns a “yes” or “no” answer. Similarly, a service is too big if it requires more than one team to manage it.
Each service has its own unique and well-defined role, runs in its own process and communicates via HTTP APIs or messaging. Each microservice can be deployed, upgraded, scaled and restarted independently of all the sibling services in the application. They are typically orchestrated by an automated system, making it possible to have frequent updates of live applications without affecting the end users.
Microservices are an evolution of a service-oriented architecture (SOA) — and some would argue that microservices are just SOA rebranded to make it hip again. But really, cloud native microservices take the SOA concept to a new level. The difference now is that cloud infrastructure has finally caught up to the SOA concept, so that loosely-coupled services (aka microservices) are now feasible to implement and manage at scale.
By enabling small autonomous teams to develop, deploy and scale their respective services independently, microservices essentially parallelize development, thereby speeding up the production cycle exponentially.
Adoption of microservices is closely correlated with the use of DevOps, continuous integration and continuous delivery (CI/CD) and containers. Container-based — and open source — systems like Docker and Kubernetes are a very effective way to develop, deploy and manage microservices. Many mature and robust tools, platforms and other services already exist in the container space, rendering containerization a natural fit for microservices-based applications.
Microservices have many advantages, but migrating away from a monolith introduces its own set of challenges. With a microservices architecture, service discovery, networking, testing and monitoring all become more complex and difficult, if not impossible, to manage following reliable older systems and practices. And the problem is amplified as the number of services grow. Tools that once seemed essential, such as logging, are now racking up huge bills that can send a microservices migration into negative ROI territory. Thus, there are many business and process decisions involved in transitioning to a microservices-based architecture.
In a true microservices approach, teams run only the exact small services they need, and nothing else. It’s a sleek setup, but these services are not aware of each other until you step in to orchestrate them. Until recently, this implementation and orchestration piece have been beyond the engineering reach of many smaller to mid-size organizations.
Fortunately, a market leap forward is now happening with microservices. There is a virtual tech sector land rush on, with companies feverishly producing not just microservices themselves, but the platforms, tools and frameworks necessary for joining them seamlessly together.
At this early stage in the developing ecosystem around microservices, it can be difficult to gauge both best fit and ultimate longevity. Despite the abundant potential benefits, microservices are not the right solution for every project. A well-built monolithic architecture can scale just as well, and remains the best option, in many scenarios.
Still, there are many companies for which microservices are the best option, and well worth the immediate challenge.
+