Microservices – Software Product Engineering Trends 2015
Industry leaders, technology evangelists and analysts predict 2015 will be the year of Microservices. The concept of microservices is taking a positive curve in 2015. More and more enterprises are looking further to replicate the successful models of Netflix, Amazon and other cloud based disruptors.
Microservices architecture Style is an approach of developing single application as a suite of small services. These small services run on their own processes and communicate with the lightweight mechanisms – often an HTTP resource API. This is opposed to the ‘monolithic’ system of software architecture.
— Docker (@docker) July 4, 2015
Although the definition of “Microservices” may vary, but there are a few common elements:
- 1. Small, single-purpose programming
- 2. Automated deployments
- 3. Endpoint intelligence
- 4. Decentralized control of language
Hence the fundamental value of Microservices lies in unlocking the potential of large monolithic legacy applications into small and independent set of composable services that can be accessed via RESTful APIs.
Let us take an e-commerce application as an example. Instead of providing all the functionality through a single monolithic application, we shall use microservices architecture which breaks the application into separate, independent services for varied functions such as credit check, order processing, order fulfillment, credit check, order tracking, and so forth. And hence the process is simplified.
— Carmen Gonzalez (@GonzalezCarmen) July 6, 2015
Let’s see how Microservices can benefit Enterprises as an integral part of software product engineering services.
Business Benefits of Microservices:
- Better Team Management : Microservices enable architects to build large systems which are composed by small services which encapsulate the functionality corresponding to a single feature. This goes in great contrast opposite to large enterprise monolithic applications. This gives certain benefits in terms of managing the teams working on such projects, dealing with code changes and their release cycles.
- Graceful Degradation : Microservices architecture give a high degree of resilience. While deploying many instances of a Microservices into the system it does good load balancing hence great resilience feature. As Microservices tend to communicate via REST and Asynchronous message buses, they degrade quite gracefully as the system comes under more load.
- Highly Efficient Team : Microservices, Agile, DevOps are different faces of the same idea. All these talk about breaking what we do into small and manageable pieces, and allowing those to work independently in parallel, hence enabling large companies to move at the speed of the small ones. Having an organized company and development teams around Microservices help fine tune and distribute results to small autonomous teams of 3-5 people responsible for one or several microservices. Such teams can make their own technology and methodology adoption choices. This makes developers feel more responsible for their small codebase and as they will be able to handle defect fixing more efficiently with full ownerships.
For Example: The Google Megastore service is developed by a small team of only 6 people. It serves the needs of several other services including Google App Engine and Google Cloud Datastore. Google Cloud Datastore is one of the largest NoSQL services in the world, yet, it has a team of only 6-8 people.
- Dynamism and Flexibility: Microservices are quite suited for dynamic cloud environment where we would want to scale up and down in response to application load. In Microservices world we are very much flexible and ca scale individual services up and down as and when necessary. On the contrary in a monolithic architecture we tend to scale the monolith horizontally by adding new nodes. Hence, microservices gives a system more dynamic property which well suits now in an elastic cloud environment.
- Heterogeneous and Polyglot: A great feature of Microservices are isolation and independence. The individual services can be polyglot in terms of programming language. This gives the ability to use ‘the right tool for the job’. You may take an example, a Node.js service interacting with the frontend via asynchronous web sockets. Clojure services could be doing some data transformation. And Java services are used for doing some of the back end integration work. Microservices fosters isolation hence we can also switch the implementation languages over time as we find the need for it. Also, there is no need for a monolithic data store with everything forced into a relational or NoSQL structure. Instead, we can allow services to have their own Datastores in a format that is most appropriate to its needs.
- Clear and Faster Process: Smaller codebases help developers focus. Developers can have higher empathic relationship with their product hence leading to more clarity of their work. The closer the relationship with the users, the shorter the feedback loop, altogether timely resolution of defects. Microservices architecture, enables delivering new functionality and iterate on the system faster than you would be able to do using monolithic architecture. Unlike in monolithic architecture style, in a Microservices architecture, a change made to a small part of the application does not require the entire structure to be rebuilt and redeployed. This results in quiet less, if not zero downtime.
- DevOps: Continuous Integration and Continuous Deployment (CI/CD) are integral in order to have successful microservices-based applications. This is required for identifying errors at an early stage where little to no coordination is required between different teams building different microservices.
— DevOps Summit (@DevOpsSummit) July 6, 2015
Certainly Microservices ain’t your free hotdog down the alley. We have seen various business, technical and operational benefits of Microservices model. But this level of architecture comes at the cost of increased operational complexity. These operational complexity comes is a by-product of things like platform heterogeneity, messaging and large number API call volumes. PaaS platforms can, however, help mitigate these challenges. Still for new businesses, because of complexity and cost of adopting microservices, taking the first steps on a monolithic system comes is simpler. They can consider the microservices if and when the need arises.
For established businesses, the decision of breaking the monolithic system into microservices definitely requires a balancing act to perform wisely. As Microservices’ are inextricably intertwined with cloud and DevOps, hence for it to sync smoothly with a Microservices architecture model requires a well-thought-out approach. It is subjective as well. But there is no denying the productivity such an organized and efficient system has to offer.
Tags: Asynchronous Buses, computer software engineering, custom software development, DevOps., ESB, microservices, microservices architecture style, Monolithic Application, Monolithic Architecture, NodeJS, NoSQL, product engineering services, RESTful APIs, Service Oriented Architecture, software product engineering, software product engineering trends