Dr. Peter Rodgers first used the term “Micro-web-services” during the Web Services Edge conference. From this, the term microservices was coined and popularized in 2011.
Microservices architecture is similar to service-oriented architecture (SOA). Small, independent software services are used to perform specific business functions. They’re often triggered by well-defined APIs that allow them to communicate with each other, combining to deliver more complex features.
Microservices are usually designed to be lightweight and cloud-native, which has led them to become one of the most used architectures.
Traditional, monolithic architectures are structured quite differently from microservices architectures. Monolithic architectures view the application as a single, large, complex piece of software. In contrast, a microservices architecture uses many small, modular services that each have their specific function to provide the same functionality the monolithic application would provide.
There are many advantages to using a modular approach like microservices. Modularity means that many engineers can work on and deliver functionality in parallel without making conflicting changes to the codebase.
This benefit continues throughout the delivery pipeline, as each microservice can be tested faster and more efficiently, ensuring faster feedback loops, improving the flow of your team’s work, and streamlining the continuous improvement (CI) and continuous deployment (CD) processes. This equates to more agile processes and less idle time for our engineering teams.
Another significant benefit of using a microservices architecture over a traditional monolithic one is that the services aren’t tightly coupled. Resiliency, elasticity, and scalability are some of the qualities that are improved by making our architecture loosely coupled.
A traditional monolithic application has three layers: the presentation layer (most commonly written in HTML, CSS, and JavaScript), the application layer, and a persistency layer (our databases and caches). These are often large pieces of software tied to specific hardware, which requires extensive re-writes to move away from.
On the other hand, Microservices are smaller applications that are often platform-agnostic. Deploying these smaller microservices has also gotten more accessible with the rise of frameworks and tools like Docker, Kubernetes, and Serverless.
A service that creates a new user is an example of a microservice. This create-user service would be triggered by a PUT HTTP request, with values being passed across for fields such as a username, password, and date of birth. This data would then be stored in a database (preferably configured with read-replicas) to be accessed in the future.
Another example that ties in with the above would be a get-user service triggered by a GET HTTP request. The full URL for this request would look something like hostname/get-user/example-user. This request provides the service with a unique username that it could then use to retrieve the user’s details from a copy of the database that provides long-term storage for the create-user service.
Both services function independently of each other. On top of being able to be deployed separately, they can also be scaled horizontally or vertically, have a stricter set of security permissions, and produce their separate logs.
These factors can lead to a more robust application that makes debugging and fixing errors easier. Being able to fix these errors faster and the improvements to the robustness of the applications means that service-level agreements (SLAs) are more likely to be met.
Several large technology organizations that have pioneered DevOps practices have also found success when adopting a microservices architecture. These include well-known names such as Amazon, Etsy, and Netflix. Each of these companies has development and production workloads running on hundreds of microservices, serving requests from millions of customers.
In the early 2000s, Amazon’s main website was built with a monolithic architecture, like most businesses at the time. Rob Brigham, a Senior Product Manager at Amazon Web Services (AWS), spoke at re:Invent in 2015 about how they had struggled with integration problems due to their monolithic architecture, which negatively impacted staff productivity. Around this time, they decided to decouple their services using a microservices model.
One example of a service extracted was a service that calculated tax correctly during the checkout process. It was decided that each of these services should communicate using only their APIs. This was coupled with some organizational changes that resulted in greater productivity and fewer issues when building, testing, and deploying services to a production environment.
Similarly, Netflix initially used a traditional monolithic architecture in its data centers. Around 2008, a bug caused the entire Netflix website to experience a complete loss of service for several hours. At this time, they had over nine million paying users. A single missing semicolon was the root cause of the bug. This missing semicolon was all it took for their central database to become corrupted.
After this incident, Netflix decided to rearchitect its systems as microservices, choosing AWS’s cloud platform for hosting. They began by moving an application that was not customer-facing to minimize any potential impact. They decided on the encoding application, which proved successful. After a successful trial, they started moving customer-facing functions such as user sign-up, movie selections, and TV selections. These changes continued to prove beneficial, and so the company continued, completing its migration by 2012. They have since stated that they have experienced significant success in scaling, which they attribute to the new microservices architecture, serving over two billion requests daily.
Read this blog post to learn how to include microservices as part of a video streaming workflow.
