Evolution Of Microservices

Application Architecture for smaller enterprises

In today’s world, we want agility in software product delivery, but are we truly agile and does our architectural patterns support it? Let us try to find out(When I said agile I didn’t really mean methodology). We have fine-tuned every aspect of the SDLC life cycle to become truly agile/lean. When it comes to development we have made several advancements in terms of technology to make development quicker in every area, from RDBS, we moved towards NoSQL, UI side we introduced new technology for better & more interactive UI, client-side processing. CI/CD pipelines but we haven’t really made ourselves agile at-least in the phase of development from architecture perspective, we didn’t come out of monolith(Don’t worry about this term, you already know more than this terminology) architecture for a long time, which was further carried over into development and later into application packaging similar way.

Let us try to understand more from layman’s term, some of you might remember for a long time, Combo TV model was quite popular because it was like one device including everything, you are getting TV, DVD Player & VCR in a single unit.

Fig 1. Typical Monolith

When anyone says monolith architecture, it is nothing but your application development & packaging is something like combo TV, where all the multiple skillset technologists in three different areas (1 TV,1 VCR,1 DVD)would have come together, would have designed everything together. Later they would have done wiring for all the devices together & try to come up with this Combo TV.

Let us see, how the above combo TV example is applicable in terms of a typical multi-tier web application. Let me elaborate more on this by adding our typical monolith application development team composition roles to the above Combo TV model.

Fig 2. Typical Monolith application layers & team composition

I didn’t mean to offend any role , I am trying to form analogy to explain it in a better way. Your typical monolith web application from eagle-eye view has Presentation layer/UI Layer, which generally your UI developers takes care of, business modules which you try to connect with your UI by exposing business module through certain pattern, which is generally taken care by your senior developers, who has an idea about massaging raw data from your backend services and converting it into business objects, further you have data layer which will be used for passing or receiving the data thorough certain DTO object & further database designer/developer develop DB tables, part of the team will be developing security module around your web application. You obviously lost the agility here, since you have a lot of disadvantages in above model

What are the problems in the above Combo TV model?

1. All the devices are interconnected.
2. During built out everyone is waiting on each other.
3. If one component is down might cause an issue for other components(TV has issue will make DVD Player,VCR useless)
4. The repair of TV might have to take the entire unit to repair station.
5. After repair you have to verify all the devices-testing
6. You might need to contact multiple technicians for each component.

Typical Multi-tier Monolith

Let us transform this example into our multi Tier online marketplace Web Application like eBay,

In multi-tier architecture it will be something like below where you are trying to deploy enterprise application on your application server, you have your web-server servicing some of the static web pages & your DB is further on a possibly clustered environment.

You have packaged as well as developed all your internal modules like inventory management, User management, Order Management and Shipping service in a single deployable unit.

Let us find out what are the issues with this approach

Fig 3. Multi-tier online marketplace architecture

What are the disadvantages in the above approach ?

1. Low Cohesion- All the components are tightly coupled.
2. Every module developer as well as developer at each tier is waiting on each other.
3. Reliability- If one component is down the whole system will collapse.
4. Low maintainability -Upgrade or issue in one module will bring down the whole application
5. Cross-cutting concerns like server startup time, difficult to test
6. You have an army of people in your agile team from the different module in each tier

To last point, you try to skin this cat to prove you are truly agile either you find full stack developers who will play multiple roles or set achievable module development goals, very low, based on your team size & their velocity or arrange sequential development of each module. Your SDLC process really didn’t get agility at least in the development/implementation phase.

It has certain advantages also, that’s why it was followed for a long time,

Advantages

1. Easier deployment
2. No need to worry about newer architectural patterns
3. No brainer scaling
4. Easy to manage

That’s where over a period of time new architectural way of implementation came to i.e SOA but again SOA has certain limitations & it might not work for smaller enterprises.

Here comes Service Oriented Architecture(SOA)

SOA addresses some of the concerns but it doesn’t address all the concerns moreover I will say technology was not that much advanced enough to address all the concerns related to containers, self-sustained applications like Sprint boot and a lot of others. SOA was a costly implementation for smaller enterprises, so everyone settled at SOA for a long duration.

In Service Oriented Architecture we divide application around mostly around coarse-grained services as per business functionality (Business Services)there are also other types of services like Infrastructure service(logging, Security, etc), Application services(fine-grained around application context).

SOA principles are more around the business as a service & reuse as much as it is possible. This forms a very big monolith around business services, where you have to follow certain common platforms across the services to make seamless communication or avoid any integration issues. Underlying you might end up using the same relational DB for all services.

SOA still didn’t provide the solution for fault tolerance to certain failures, you might still end up in a situation if one system is down causing application is not able to fulfill customer orders in our earlier example of an online marketplace.

Not everyone was able to procure infrastructure for SOA implementation like ESB, when I meant everyone I meant smaller enterprises.

That’s why Microservices Architecture(MSA)

Microservices architecture was not invented it gave benefits to Netflix & Amazon. That’s why they went ahead & adapted it. Microservices are relatively very small SOA components & developed by a team of size, who can be feed by one large size pizza.

What is Microservices in terms of our Combo TV options?

Fig 4. Typical Microservices Architectural end products

Here we chose the best product like TV, VCR, Sound System, etc from reliable vendors. We got the best out of everyone & we can selectively use every device. The issue in VCR doesn’t create an issue in other devices. We kind of overcame all our disadvantages

1. All the devices are separate.
2. No one is waiting on each other.
3. If one component is down the rest of the components are working
4. After repair of one device, you verify only that device

Online marketplace design using MicroServices Architecture(MSA)

There are multiple architectural patterns I am just trying to give one possible way of designing the same application using MSA.

Fig 6. Implementation on the online marketplace using MSA

As you can see our online marketplace application is broken down into multiple services & exposed as individual lightweight rest api to communicate. Also, you would have observed that each application has its own DB, on its own container(VM/Node). UI has separated from back-end service so complete independence.

This gives you provision of procuring best DB for each operation type, like lookup in case of inventory management NoSQL might make best fit other places might RDBMS makes more sense.

Whatever disadvantages were in your typical monolith development model had been overcoming.

Advantages:-

• No vendor locking like in SOA
• Diversity in terms of not marrying with any technology
• True agility since very small functional or infrastructure services
• Get the best fit for the job to get it done
• High Cohesion since the separation of responsibility

There are certain disadvantages to Microservices Architecture also

Disadvantages:-

• Complexity, since each service on its own, became self contained, it raises a lot of concerns related to the handling of data across services, API gateway, Security, aggregation of logs at one place, reporting for datawarehouse, inter-service communication.
• Security Concern, now that everything is scattered around you might have to take care of security concern
• Cultural shift, suddenly DevOps becomes primary focus & mindset needs to be adapted.
• It becomes costlier since you need supporting infrastructure to support MSA.

Conclusion :-

Microservices Architecture is not necessarily fit for all the possible business ask. It clearly needs to be thought before any business ask was considered as a candidate for Microservices. Microservices is not a silver bullet for everything otherwise you will end up in building up and maintaining a large set of services, which became difficult to manage. It adds complexity at multiple places from the development phase until the end of the SDLC life cycle. Some of the cross-cutting concerns need to be addressed before you truly start following MSA, it is a little bit of a bigger lift for initial setup, which might not justify the effort in terms of business ask. Not all the projects have supporting infrastructure to follow this architecture and if you force yourself in that direction you might end up in building pseudo Microservices.

Please look forward to my upcoming write-up on Architectural Patterns in Microservices, if you have decided microservices are the fit for your business need.

Published by Sachin Kapale

Sachin Kapale is having IT experience of 18+ yrs,with multiple MNCs & fortune 500 clients. He has certifications in Orale,JAVA,Websphere, UDB, HP area. He currently plays multiple roles in Architectural space. He works with senior management to establish strategic plans and objectives, document technical strategies to facilitate operational business needs , Assess systems requirements and design against best practices, technology advances, industry standards, and business needs. Provides direction on implementing feasible, cost-effective solutions to the overall system architecture and design to meet these needs Also Sachin works closely with Health Services Operations management and staff, Operations Systems’ technical engineers, and process engineers to provide guidance and ensure adequate design for meeting Health Services’ business objectives and strategy & Serve as the key technical point of contact in developing the technical solutions in response to Request for Proposals, Change Requests, and business needs. Sachin also reviews federal, state, and company policies to determine applicability to systems functionality, design, and operation. He also develops strategies to fulfill requirements and assess the effectiveness of implementation. He also collaborates and coordinates with appropriate internal and external groups to ensure the confidentiality and security of all corporate information His expertise is in designing microservices-based architecture on cloud based as well as containerized environments. Working as a success serving as a key point of contact for the design of complex information technology solutions. He has technical papers presentations on Web 2.0. He can perform comfortably in a fast-paced, deadline-oriented environment Perform quantitative and qualitative analyses of existing business processes based on in-depth industry knowledge of organizational and client objectives His current passion is Cloud based architecture, Artificial Intelligence, machine learning in healthcare call center business and in the back office area.View all posts by Sachin Kapale

About Sachin