WHITE PAPER Microservices: Embracing the Unix mantra Practice Head: Srini Peyyalamitta srini.peyyalamitta@aspiresys.com Author: Revathi Chandrasekharan Technical Lead - Software Engineering Aspire Systems Consulting PTE Ltd. 60, Paya Lebar Road, No.08-43, Paya Lebar Square, Singapore 409 051. a t t e n t i o n. a l w a y s.
C O N T E N T S Introduction Revisiting Monolithic Style Splitting the Monolith into Microservices Rapid Application Development Microservices - Implementation and Challenges Memory Consumption Network Overhead Data Management Issues Fault Tolerance Versioning Vs Tolerant Services DevOps Testing Conclusion Aspire Systems - Microservices: Embracing the Unix mantra 2
Introduction In recent times, the term Microservices has gained immense popularity. It has found advocates in big players like Amazon, Netflix, NGINX to name a few. These companies have adopted this approach and have shared their first-hand experiences which are quite impressive. There is a growing inclination towards this approach. The Google trends for Microservices also corroborate the same. Web apps / Mobile apps Integration Layer So, what is Microservices? The term Microservices was coined to define an architectural style which proposes developing and maintaining an application as multiple small independent deployable units, specifically as services, that communicate via APIs. There are no hard and fast rules as to how many individual services your application should be made of or how the breakdown should happen. Neither is there a specification as to the size of each unit. The only criterion is that each service should handle one responsibility and do it well. This is in unison with the core philosophy of UNIX Make each program do one thing well. The following diagram illustrates a payment gateway solution built as a set of services with each individual service for dedicated for each of the payment channels and an optional integration layer which is also built as a Microservice. Before we get into the implementation details and the benefits this approach has to offer, we need to understand the traditional approach to building software - the Monolithic Style. Revisiting Monolithic Style A product built as a monolith is a large deployable unit that includes every component of the product bundled together as a single unit. The overheads of an application built following this style are explained below. Irrespective of how you choose to handle deployment - in-house or cloud, one of the major challenges any application with a growing user base faces is handling the traffic and the load it adds to the servers. Easiest way to overcome this challenge is to add resources to your infrastructure. In case of a monolithic application, you basically deploy it in different instances and your load balancer will handle the rest. However, this is not a cost effective solution. You would ideally want to spike resources for the part(s) of the application that are CPUintensive. Unfortunately, since the product is built as a monolith, selective scaling is next to impossible. Aspire Systems - Microservices: Embracing the Unix mantra 3
Shelf life of a software product depends on a wide range of reasons, spanning from business decisions and changes they necessitate to how well or how badly you have written the code. Since there is lot of money and time invested in building the product, you would want the shelf life to be longer, provided it can meet the market demands as it evolves. There is very little control that can be exercised on the business changes. But you have to do have some kind of control, if not absolute, on the later. If your code is written following the principles of Modularity (Loose Coupling, High Cohesion - all easier said than done) and all the other governing laws of elegant software building, you will actually be able to deal with the changes quite easily. But the big IF clause is very difficult to pass, especially if it is a monolithic application. Say there is a bug in one of the modules that is causing memory leak or there is a module that adds too much load on the system and literally brings the application down. In both these cases, the problem is isolated but the entire system has to bear the consequences. We live in a world where there are new and better things every other day and this is equally true for technology as well. A programming language or a framework, which is considered the best today, can be rendered obsolete tomorrow by the advent of some other superior language or a better framework. Or what was considered as the best technology stack when the product was conceived may turn out to be lacking key aspects as the product evolves. Solution to both the aforementioned cases would be to go for what is termed as. But it is not without cost. Considering that your product is already out in the market, you can neither risk doing something drastic nor let instability lurk around. On the other hand you cannot live with the inadequacies of your current technology stack. Technology upgrade is safer and best when done gradually. With a monolith, a gradual migration of technology stack is almost impossible. If you opt to build a product using the Microservices style instead, you can overcome all the above limitations to a great extent. Let s quickly reiterate through these limitations and see how these can be overcome using Microservices. Splitting the Monolith into Microservices Selective scalability is one of the inherent advantages of the Microservices architecture. As mentioned earlier, there might be certain operations that can spike the load of the system and make your entire product slow or sometimes even make it non-responsive. If you were to pull it out as a separate service that is hosted in a dedicated server, rest of the product doesn t have to bear the brunt of the super intensive consumption of resources by this operation. Modularity is easier to achieve when you build your product as a suite of smaller units or services each designated for a clearly defined responsibility. Each service can be guided by a set of principles best suited to the kind of problem it is meant to address. Over a period of time, even if a couple of services cease to be relevant or need a complete replacement, the rework would be restricted to those services alone which would be lot cheaper, less risky and less time consuming than a monolith. Aspire Systems - Microservices: Embracing the Unix mantra 4
The fault isolation that is achieved by implementing the modules as services guarantees high availability. Also, the flexibility to scale up your services selectively on demand also contributes to Network Overhead The in-memory calls that you would make in case of a monolith would be replaced by the likes of REST, Protocol Buffers, Thrift etc contributing to an added latency. Microservices provide greater flexibility in terms of technological choices than a typical monolith. Based on the type of service you are building, you can choose a technology stack that best suits its needs. Technology migration can be achieved incrementally as well. Rapid Application Development Business demands sometime require a product to be built and available in the market in quick turnaround time. The increasing nature of such demands is what gave birth to frameworks like Ruby on Rails which aid in Rapid application development. The usage of Microservices gives an extra edge in this aspect. You can develop and release a subset of features developed as services. One might argue that this process known as iterative/agile model can be and have been followed for products built as a Monolith as well. True. However, Microservices takes this one step further by providing the ability to add or remove a feature or a module without actually disturbing the rest of the application and that too at the necessary Rapid pace. In short, the whole process becomes more streamlined and effective. Microservices - Implementation and Challenges Memory Consumption The memory consumption is relatively more than a monolith mainly because of the multiple deployable units in Microservices as opposed to one in the monolith. Data Management Issues With an implementation pattern where the completion of one request may span multiple service calls and each of them issuing its own transaction, comes the inherent need to implement distributed transactions. Distributed transactions are not easy to implement, they are costly and can cause lot of trouble if not implemented right. The preferred option to handle this problem is an approach that is called Eventual Consistency. Eventual Consistency is defined as a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. For example, the user action may require two requests to be completed by two different services. The action isn t complete until both the requests are processed. Say that the first request is completed and the second request is queued. So till the second request gets completed, the end user may be seeing some incomplete, incorrect data. This is allowed with the expectation that it will get resolved eventually. Fault Tolerance Any application that involves interactions through the network should be prepared for the probable failure scenarios in one or more services. 1. If there is an integration service (as shown in the diagram) involved. 2. If the integration service fails everything is brought to a grinding halt. Hence Microservices place a lot of importance in ensuring that the system is equipped to handle and recover from such cases. Building monitoring mechanisms is recommended so that failures can be identified and addressed as soon as they occur. Aspire Systems - Microservices: Embracing the Unix mantra 5
Versioning Vs Tolerant Services One of the most critical aspects while developing services is the contract that you establish and share with the consumers of the service. How do you ensure that the change to the service contract or the implementation does not necessitate a change in all the consumers? For example, consider that you enhance a particular service to meet the demands of one particular consumer. Will you request all the other consumers to update their implementation even though they derive no discernible use from the change? You have to unless you use one of the two options - Versioning or Tolerant services. Versioning involves retaining the old version(s) while you roll out the updated versions and have the consumers use a version of the service based on their need. This of course adds an additional overhead of deploying and maintaining multiple versions of the same service. The preferred approach is to develop your services as what is termed as Tolerant way. In this approach, the schema is designed with minimal restrictions and validations. The consumers are meant to extract data that is required and ignore what is not. Testing Any distributed system demands more rigorous testing as the collaboration among multiple components open the possibility for more failures. Microservices is no exception to this. Unit Testing - most important, yet most neglected aspect of software development cycle. It is imperative that unit tests are implemented and their execution is part of your continuous integration strategy. Over and above this, contract testing and integration testing needs to be performed. Conclusion In conclusion, building a product as Microservices is not easy. But it is hard to overlook the many benefits accrued by using this approach. Of course, the success or failure of this approach also depends on the extent of understanding, thought-process and discipline that goes into the business strategy and implementation. So, it is crucial that all the challenges and strategies are thought through before going ahead with the implementation. DevOps Successful execution of Microservices requires the entire build and deployment to be streamlined and a good collaboration be established between the development and the operations team. The build and deployment processes should be automated using Continuous Integration and Deployment tools. Using the likes of Amazon Web Services, the infrastructure management can be simplified as well. The DevOps strategy needs to include a thorough monitoring mechanism that will monitor every aspect of the deployment right from server health to CPU and memory usage, log monitoring and API usage. Having such monitoring mechanisms is required to recover quickly from any possible failure. Aspire Systems - Microservices: Embracing the Unix mantra 6
References http://martinfowler.com/articles/microservices.html https://www.nginx.com/blog/introduction-to-microservices/ https://smartbear.com/learn/api-design/what-are-microservices/ ABOUT ASPIRE Aspire Systems is a global technology service firm serving as a trusted technology partner for its customers. The company works with some of the world s most innovative enterprises and independent software vendors, helping them leverage technology and outsourcing in Aspire s specific areas of expertise. Aspire System s services include Product Engineering, Enterprise Solutions, Independent Testing Services, Oracle Application Services and IT infrastructure & Application Support Services. The company currently has over 1,600 employees and over 100 customers globally. The company has a growing presence in the US, UK, Middle East, Europe and Singapore. For the seventh time in a row, Aspire has been selected as one of India s Best Companies to Work For by the the Great Place to Work Institute, in partnership with The Economic Times. SINGAPORE +65 3163 3050 NORTH AMERICA +1 630 368 0970 EUROPE +44 203 170 6115 INDIA +91 44 6740 4000 MIDDLE EAST +971 50 658 8831 Aspire Systems - Microservices: Embracing the Unix mantra 7