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 SDLC life cycle to become truly agile.  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, better CI/CD platforms 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 in terms of layman’s term , some of you might remember for a long time below TV Combo 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 say monolith architecture, it is nothing but your application development & packaging is something like combo TV, where all the multiple skillset technologist in three different areas (1 TV,1 VCR,1 DVD)would have came together, would have designed everything together. Later they would have done connecting 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 typical multi tier web application. Let me elaborate more on this by adding our typical monolith application development team composition roles to 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 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 lot of disadvantages in above model

What are 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 issue for other components(TV has issue will make DVD Player,VCR useless)
4.  Repair of TV might have to take 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 components.

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 single deploy-able unit.

Let us find out what are the issues with this approach

                                            Fig 3. Multi tier online marketplace architecture

What are 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 whole system will collapse.
4.  Low maintainability -Upgrade or issue in one module will bring down whole application
5.  Cross cutting concerns like server startup time,difficult to test
6.  You have army of people in your agile team from different module in each tier

To last point you try to skin this cat to prove you are truly agile either you find a 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 atleast in 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 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 concerns but it doesn’t addresses all the concern 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 lot of others. SOA was a costly implementation for smaller enterprises, so everyone settled at SOA for 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 business as a service & reuse as much as it is possible.This forms very big monolith around business services,where you have to follow certain common platform across the services to make seamless communication or avoid any integration issues. Underlying you might end up using same relational DB for all services.

SOA still didn’t provide 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 order in our earlier example of 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 best product like TV,VCR,Sound System, etc from reliable vendors. We got best out of everyone & we can selectively use every device. Issue in VCR doesn’t create 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 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 same application using MSA.

                      Fig 6. Implementation on 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 it’s own DB ,on it’s own container(VM/Node). UI is 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 overcame.

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 separation of responsibility

There are certain disadvantages to Microservices Architecture also

Disadvantages:-

•  Complexity, since each service on it’s own became self contained, it raises lot of concerns related to 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 & mind set need to be adapted.
• 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 be end up in building up and maintaining large set of services, which became difficult to manage. It adds complexity at multiple places from development phase till end of the SDLC life cycle. Some of the cross cutting concerns needs to be addressed before you truly start following MSA, it is little bit of bigger lift for initial setup, which might not justify 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 for my upcoming write-up on Architectural Patterns in Microservices, if you have decided microservices is the fit for your business need.