Let’s take for instance a simple tech news website that has three microservices. “Service A” is tasked with serving the main website content with a caching layer, “Service B” handles all the subscription and payments through the website, and “Service C” handles serving articles.
Scalability
One of the main advantages of using microservices is that you can scale each service separately. We’ll go over two scenarios to demonstrate scaling microservices.Scenario 1
It’s 8 AM and everyone is commuting to work. During their commute users check the latest tech news. In this case, users of the website are reading the trending and latest articles on the homepage. “A” will need to scale to handle all the requests coming from the users, while the caching layer will allow the articles to be served as fast as possible without talking to “C”. Talking to a database is the most expensive part of serving content on the web, and the caching layer allows us to minimize the number of requests to “C”. At the same time, the main audience of the website at that point in time is not subscribing and paying for their subscriptions, which are the functions served by “B”. Would it make sense to scale all services? It wouldn’t because we only need to serve the main page and articles. In this situation, we can successfully provide a fast experience to our users by only scaling “A”.
Scenario 2
The marketing team of the news website just launched a campaign on social media to promote their new subscription model offering a discounted first year. In this case instead of scaling “A” we need to scale “B” because “A” is offloading subscriptions and payments to “B”.
Releases in microservices are safer since in the worst case scenario you end up with a degraded system avoiding complete downtime on the website.
Great! Microservices architecture is revolutionary! The biggest mistake in the development community is blindly pushing for a specific framework, architecture, or pattern that doesn’t fit the needs of the specific project. Monolithic architecture has worked (and still works) for decades in some of the biggest companies in the world. A Microservices architecture adds a lot of complexity to your application, which might not be needed or worth the effort. Some examples are monitoring, distributed tracing of requests, service discovery and inter-service communication.
Thinking about the architecture and design of an application is the most important part of the development process. When starting a new project where you think Microservices architecture fits, a common strategy is to design the application using a Monolithic architecture first. Figure out the complexity of the modules in your application and based on that break it down to microservices. An application developed using a Monolithic Architecture with a modular design that allows you to split out the application at any point of time helps a lot. A great article about this is Martin Fowler’s MonolithFirst approach.
This article gives my opinion on Microservices Architecture and some thoughts about it, it’s in no way a comparison between Microservices and Monolithic Architectures. For example, I mentioned MonolithFirst and while I think it’s a nice strategy it doesn’t work for all projects and teams. In an effort to provide both sides of the argument here is an article that contradicts the MonolithFirst concept.
It’s completely up to the development team to decide what’s best for the project and looking at all the options is the way to do it.
Maintainability
When using microservices architecture the codebase of the project is divided into isolated services. Larger teams where multiple engineers work on the same project can encounter problems such as merging code from multiple features branches to the trunk branch. In our news website example from above, we can have a team working on service “A” that handles the main website content, another team focusing on payments gateways and integrations on service “B”, and finally, a team focusing on the Content Management System (CMS) on service “C”.Releases
When following a microservices architecture, services are independent of each other and follow their own release pattern. Unlike Monolithic architecture, we can make releases to a specific service without deploying the whole application which can be expensive and risky in many situations. Releasing service “B” to provide an additional payment method for users or fix a production issue is straightforward. This goes hand-in-hand with Continuous Delivery and Immutable deployments which I’ll talk more about in another post.Releases in microservices are safer since in the worst case scenario you end up with a degraded system avoiding complete downtime on the website.
Great! Microservices architecture is revolutionary! The biggest mistake in the development community is blindly pushing for a specific framework, architecture, or pattern that doesn’t fit the needs of the specific project. Monolithic architecture has worked (and still works) for decades in some of the biggest companies in the world. A Microservices architecture adds a lot of complexity to your application, which might not be needed or worth the effort. Some examples are monitoring, distributed tracing of requests, service discovery and inter-service communication.
Thinking about the architecture and design of an application is the most important part of the development process. When starting a new project where you think Microservices architecture fits, a common strategy is to design the application using a Monolithic architecture first. Figure out the complexity of the modules in your application and based on that break it down to microservices. An application developed using a Monolithic Architecture with a modular design that allows you to split out the application at any point of time helps a lot. A great article about this is Martin Fowler’s MonolithFirst approach.
This article gives my opinion on Microservices Architecture and some thoughts about it, it’s in no way a comparison between Microservices and Monolithic Architectures. For example, I mentioned MonolithFirst and while I think it’s a nice strategy it doesn’t work for all projects and teams. In an effort to provide both sides of the argument here is an article that contradicts the MonolithFirst concept.
It’s completely up to the development team to decide what’s best for the project and looking at all the options is the way to do it.
Comments
Post a Comment