The Evolution Of Software Architecture

05
Apr, 2018

by Filip

Introduction:

Ever since software applications outgrew basic scripts and binary executables that would have a single purpose, there has been a need to introduce some sort of design into how we structure software. Design of software on a high level is known as the Architecture of Software, it is independent of the programming language being used as well as the operating system that the software will run on. The purpose of this article is to explains the evolution of software architecture from Monolithic up to the Service Oriented Architecture also known as SOA. The following paragraphs explain each one of the three evolutionary stages in software architecture.

Monolithic Architecture:

Initially software solutions were built as a single physical piece that was divided into logical pieces. The logical division was introduced to create sort of a hierarchy and structure into the software design. This architecture was known as the Monolith. There were three parts of the monolith: user interface also known as the view, service logic also known as business logic and data layer also known as storage. The service logic layer was in charge of processing the data in a desired manner to complete the business purpose of the service. The role of the storage layer was to permanently store data. The simplicity of the monolith architecture was its greatest advantage. This kind of software was usually deployed on a single machine and scaling it only required vertical scaling of that machine. Due to the fact that the monolith software could only be scaled by vertically scaling the single machine the architecture became obsolete and unsustainable once web applications started being widely adopted and number of requests exceeded the scaling capabilities of vertical scaling.

Tiered Architecture:

Once the scaling needs exceed the scaling capabilities of the monolith architecture the logical division of the monolith was converted to a physical division. The user interface layer became the Web UI, the Service logic became the Web Service and Storage was its own piece existing in separate machines usually dedicated DB servers. This physical division allowed for horizontal scaling to scale the software enough to meet its needs which increased exponentially with the wide adoption of web applications in everyday life. This required some changes in the parts themself, webservices had to become stateless, the storage layer had to become become distributed with implemented synchronization mechanisms between the nodes, Web UIs needed their own servers on top of which they will run on. Once web applications were adopted as the new standard of solving everyday life problems, finding an apartment, buying a car, paying for parking even using the tiered architecture which was scaled both vertically and horizontally this architecture could not meet the scaling needs and sustainability demands of web applications. Scaling become an even bigger problem when mobile application adoption was growing more and more thus increasing the urgency for further evolution of software architecture.

Service Oriented Architecture:

The previous evolution step turned a horizontal structural division into a physical one. The step from tiered architecture towards the service oriented architecture did a similar division of the web service layer and the storage layer. Due to the fact that the Web Service needed to provide more services than one it made sense to make the vertical division into different services based on the function they provided. This division is usually a case to case basis per application so the image depicts only one variation of this architecture. In the given example the web service was split into the following parts: Search API which is a web service that provides search functionality on top of the live/hot data in the system, Data API which is a web service that provides only simple key/value access to the live/hot data and the Analytics API which is a web service that provides analytics insight on top all of the data both live/hot and old/historical. As the division happened in the middle web service layer this also required the storage layer to be divided so that specific storage solutions can be used to suit the needs and the roles for each of the service. As an example search API requires indexed data for fast lookup, sorting, comparing etc. One of the most commonly used solution that provides search as a feature is ElasticSearch. As far as the Data API layer it requires cheap storage for large volumes of data that only needs to be accessed by one key, there are numerous solutions that provide this kind of key value storage solutions like MongoDB, Cassandra, Zookeeper etc.. The Analytics Service has the need to do mathematical computations on large sets of data as well as keeping a lot of historical data this usually requires a complex data warehousing solution underneath. Data Warehousing solutions are too complex to be described in this chapter but just to give some insight one example could be all of the data that ever existed in the system and is stored in HDFS where you can run HBase queries on top of it. Other examples of Service oriented architecture could have a separate Authorization Service if you application requires users to authorize themselves, Image Service if you have a lot of image processing in your application, Notification service in case you applications sends notifications to users, etc.. This architecture once implemented properly is easy to scale and can be sustained by monitoring performance of each service as well as splitting up services into new ones.

Conclusion:

Next step in the evolution of software architecture is yet to be done. Some would argue that the evolution has already reached its next step with the introduction of Microservices. Microservices are definitely widely used but as more and more companies start breaking up their services into microservices a pattern is being notices that the overall latency is increasing as well as IO usage. So before we make a conclusion if Microservices are the next level in the evolution software architecture we will wait for a while to see how they fare in production systems for some time.