Contact
Your business is growing bigger. But are you sure that your existing business implementation can perfectly cater to the increasing number of clients? Say, more customers are logging in for your web solution from mobile phones, tablets and other wearable gadgets. Does your application support all of them?
Upgrading your existing software to cater to the increasing demand is surely the solution, but it is definitely a mammoth task. Wouldn’t it be easier if you have each of your functional services as an independent block of codes that can be tweaked and upgraded faster? Microservices is the solution for such an implementation in your business!
The Microservices architecture (or Microservices) essentially means implementing a business solution as a suite of small services, each spooling as a process and serving a single function. Because of the low complexity and singular functional goal, implementing, testing, deploying and upgrading each service become an easy task. By using lightweight and stable communication methods in between services, integrating the services solutions is efficient too.
Software engineering has evolved over the years and the discussion about microservice architecture began in 2011 at a software architecture workshop in Venice. The term ‘microservices’ was coined in 2012, as it was found to be the most appropriate among the developers who were exploring this new software architecture model. James Lewis presented his ideas about microservices in March 2012 at “Java- the Unix Way” at 33rd Degree. In the latter part of the year, Fred George presented his ideas about “µService Architecture” at Baruco.
All this while, Adrian Cockroft of Netflix was pioneering this style in web scale. Apparently, developers and software architects across the world could see the need of a better architecture to support the future clients and started thinking in the same lines resulting into microservices!
It is evident that developing software applications as a suite of small, independently deployable, modular services would make the entire development process agile. At the same time, there is a need for each of the service processes to communicate through a well defined and lightweight mechanism to achieve a functional goal. Often, how the services communicate with each other is dependent on the application’s requirement.
The most stable communication interfaces used in microservices are HTTP, JSON and REST (Representational State Transfer). This is mainly because HTTP is a broadly available communication protocol and it is supported by most platforms. Hence it is the standardised interface over internet and allows scaling as well. JSON provides a simple data representation format and can be mostly validated. REST provides ideas and principles for leveraging HTTP and JSON to build adaptable microservice interfaces. So far, REST is the ideal architectural style for distributed systems built on the web.
With all the above details, at least for a few of you, microservices will look like a refined form of SOA (Service Oriented Architecture). In SOA, the architecture follows a horizontal layered approach to split the functions into different modules. Many Enterprise Service Bus (ESBs) are used to transfer data between the layers, and usually involves a huge relational database.
Microservices on the other hand, builds services using a vertical layering approach that demarcates the functionality of each and provides independent goals. Implementation is done with responsive programming using faster messaging mechanisms along with micro SQL databases. Microservices can be put together as ‘an enhanced Service Oriented Architecture (SOA) that is less complex and uses efficient data handling’.
Whenever there is a change in management or a new domain acceptance or a shift in business priorities, your organisation gets shaken up to implement the same with ease. By following a refined SOA approach in your organisation, you can actually distinguish the impact of the same and easily cascade it to your teams for implementation. Implementation frictions are reduced by allowing complete freedom for the developer teams to analyse the issue and address them separately with proper co-ordination.
Check out the benefits of Microservices to see if your organisation really needs this.
Having said all this, microservices surely come with a lot of advantages for your organisation. Let me show you in detail how it scores over monolithic architecture.
Most organisations follow Monolithic architecture as the normal way of implementing an application. In monolithic architecture, say for a web based application, your approach is to build the User Interface (or the Presentation Layer), work on the Application Layer (where the main business logic is implemented), create an integration Layer (to connect the various components of Application Layer) and a Database Layer. Now everything is packed under one EAR/WAR to run it, deploy on an application server (say TomCat).
Microservices scores above Monolithic Architecture in the following ways:
Well, that is decent enough data to vouch for Microservices. Let us now look into the details of developing microservices for your organisation.
The first and foremost thing to consider while building microservices for your business is when to start with it. If you are developing the first version of your application, going for microservices approach will delay the entire development process. The advantages of microservices may not even make significant sense to your application in the initial days. On the contrary, if you are thinking about scaling up your application or want to reduce the complexity of running a mammoth application to small functional modules, microservices is the ideal solution.
Going for the microservices approach will definitely help you in the long run. Before moving ahead, understand that setting up a distributed system is a complex process. The current developer tools and IDEs support monolithic approach and so you actually don’t have a clear system for developing microservices. The inter process communication system is the critical part and developers have to build it by themselves for effective communication between services. All along the development and testing phase, different service teams have to work in co-ordination to implement use cases spanning multiple services.
Deployment of microservices is extremely complex, as you have to operate and manage a system comprising of different service types. Moreover, each service instance is isolated and needs memory on its own. And often running each instance requires an exclusive compiler instance run as well. For example, if there are M microservices and it is run over N server applications, it requires ‘NxM times’ instances and ‘M times’ of JVM (or equivalent) runs in each of N server applications. Be prepared for heavy memory usage while implementing microservices.
Firstly, partition the system into microservices. Each microservice should have only a small set of responsibilities. Following the SRP (Single Responsibility Principle for designing classes) design approach while developing services will help in this regard. According to SRP, a class is responsible for a reason for change and should have only one reason to change. That is exactly what a service should also focus on.
Two common strategies used for partitioning services are based on (i) verbs or use cases and (ii) nouns or resources (entities). An example for using verb approach on web would be creating a login service for implementing login use case and a shipping service for implementing shipping completed orders. Similarly, based on resources, an ecommerce application can have an inventory service that tracks the stock of products.
As James Lewis presented, microservices can be built as Java implementation in a Unix approach. A Unix system uses large number of utilities like find, grep and cat, each focusing on one single thing and individually works exceptionally well. Unix allows you to combine many such utilities using a shell script to perform complex tasks.
Secondly, work on the efficient communication strategy between services. Messaging and Remote Procedure Calls (RPC) are the best options.
Thirdly, work on how each service has its own database. For example in case of relational databases, you can go for
(i) Private Tables Per Service – each service owns its own set of tables, making them inaccessible to other services.
(ii) Schema Per Service – each service has its own private database schema that will do the mapping and fetching.
(iii) Database Server Per Service – if it is high throughput service, it will need its own database server
Fourthly, work on packaging the services and Deployment strategies. You can choose from:
(i) Single Service Instance per Host – deploy each single service instance on its own host. A refined approach to this can be deploying service instance per VM or service instance per container. This will make each service isolated, hence no possible conflicting resource requirement and it’s easy to manage and monitor. It contrarily results in inefficient resource utilisation.
(ii) Multiple Service Instance per Host – run multiple instances of different services on a host making efficient resource utilisation.
(iii) Serverless Deployment Pattern – you deploy your code into deployment infrastructure and describe the desired performance features. You will be charged based on the resource consumed per requests, while being completely hidden from the use of servers or VMs or containers. Deployment infrastructure is a utility environment operated by public cloud provider and examples are Google Cloud Functions and Microsoft Azure Functions.
Similarly, at the client side, decisions are to be made on how the client service requests are routed to an available service instance that is viz., client side discovery or server side discovery. You should also work on how the client accesses the services, probably using API Gateway pattern.
Yes, it looks extremely complex to implement microservices for your business. But the organisations that have done it have benefitted from it very much. Amazon, eBay and Netflix are the giants who took the leap of faith in implementing microservices.
Amazon.com with a monolithic two tier architecture, moved to a SOA architecture to scale up. It has hundreds of backend services and each Amazon web application, including their web service API, calls these services. For example, the web application calls 100 to 150 services, to bring up its web page. This scalability was impossible with the earlier mammoth monolithic model.
Netflix, the video streaming web application that is responsible for 30% of web traffic adapted from a massive monolithic to larger scale SOA architecture. It supports 800 devices resulting in more than a billion calls to the video streaming API every day. Each API call results in an average of 5-6 service calls in the back end. Netflix easily supports more customers than it ever could, thanks to the microservices implementation.
With the intervention of multiple device support, increasing user base, Internet of Things, and interaction with different technology models, software development has become a complex process. Further, it is highly complex when it comes to upgrades. Microservices come as a perfect solution to application developers who are forward thinkers.
Microservices is a journey that will affect your organisation culturally, technically and operationally. It is the way forward in the development of enterprise applications, giving your organisation the freedom to adapt easily according to the future!
Want to know more about how Microservices can help your business run efficiently? We’ll be happy to guide you!
YOU WILL BE HEARING FROM US SOON!
We look forward to hearing from you!
YOU WILL BE HEARING FROM US SOON!
