Microservices Architecture
Last updated
Was this helpful?
Last updated
Was this helpful?
Service resources in Kubernetes are loosely referred to as
microservices. Kubernetes lets you break down an application into modular components and enable them to exchange data in a Kubernetes cluster through services. This use of services in Kubernetes helped popularize the term microservices, which in early discussions of service-oriented architectures before the existence of Kubernetes.
Microservices are a modern architectural pattern for building an application. A microservices architecture breaks up the functions of an application into a set of small, discrete, decentralized, goal-oriented processes, each of which can be independently developed, tested, deployed, replaced, and scaled.
As small, discrete application components linked together through lightweight, well-defined APIs, microservices can be linked together in various ways to create modern applications with independently scalable modules. Another major advantage to this application architecture is that discrete components can be updated independently, which enables developers to efficiently deliver new features and fix issues with existing ones. The business value of this approach is clear: You can get new digital products and services to your customers with phenomenal speed and efficiency.
Consider a three-tier app that has a front end, a middle app tier, and a database. Traditionally, this app would be deployed in three different virtual machines. To use microservices, the same app would have the front end broken into further components. For example, the front end can be broken into services that each handle login, catalog, services, feedback, etc.
The middle tier could be broken into services that handle authorization, database connections, metering, etc.
With this modular approach, development teams can push an update to the Catalog Page without having to touch or update any of the login or database functionality.
Here are some of the key technical aspects of microservices:
Strong and clear interfaces – Tight coupling between services must be avoided. Documented and versioned interfaces help to solidify that contract and retain a certain degree of freedom for both the consumers and producers of these services.
Independently deployed and managed – It should be possible for a single microservice to be updated without synchronizing with all of the other services. It is also desirable to be able to roll back a version of a microservice easily. This means the binaries that are deployed must be forward and backward compatible both in terms of API and any data schemas. This can test the cooperation and communication mechanisms between the appropriate ops and dev teams.
Built-in resilience – Microservices should be built and tested to be independently resilient. Code that consumes a service should strive to continue working and do something reasonable in the event that the consumed service is down or misbehaving. Similarly, any service that is offered should have some defenses with respect to unanticipated load and bad input.
Sizing of microservices can be a tricky thing to get right. Natural boundaries such as languages, async queues, and scaling requirements also serve as useful dividers.
Here's a video by a former Netflix architect that gives you the lowdown on using a microservices architecture for building next-generation applications. Find out how microservices fit into the larger picture of releasing software early and often, using agile development principles, adhering to lean programming techniques, integrating with CI/CD pipelines, and implementing security.
Now, that you know how to run what you wrote while adhering to the principles of faster, cheaper, and safer, check out the following paper, which is less than a 5-minute read: