Service-Oriented Architectural Software Design with Agile and DevOps
World is full of data. Every industry...! Every department...! Every sector..! Lets Take hospitals. Managing data like patient’s data, pharmacy data, laboratory data, diagnosis history, payment data and many are really complex if we do not have proper system. Here the word managing means that creating such data, storing such data, extracting or make use of this data (Of Course! a typical software application). The phrase proper system means that an application which gets information from creating patient’s entry to exit, Keeping data in safe and secure, extract the data for report and analysis(Of Course! a typical software application).
So what is happening here is playing around data with software applications. So nothing is new here, Rite.! well organized applications are already available in market and people are so comfortable with using it. So what is the problem?
Whether your software application is failure safe? really scalable? cost effective? So this is the problem. How can we overcome this problem? Yes we need to evolve in terms of software architectural design to overcome this challenges. Adopting your applications to Service Oriented Architecture is that new evolution which we need to evolve.
What is service oriented? And how this differs from traditional Architecture?
Traditional Architecture is tightly coupled and all applications can be horizontally scaled with the same tightly coupled applications. But modern architectural design suggests that we need to split the application into small, independent dedicated decentralized chunks.
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
-- Martin Fowler
So problem with traditional architecture is that it is not failure safe. You may think that horizontal scaling will be more than enough to make it failure safe. But it’s not!! What if the load balancer fails? Yes if load balancer of tightly coupled applications fails then entire application will go down. Isn’t it?
So the word elasticity may solve this problem. Implementing architecture with elastic load balancers is the optimal and true way of scaling the application.
Basically elastic load balancing can be obtained with many ways. One with having multiple CNAME in DNS, one with having elastic IP or floating IP and many ways. Technic or methodology is all about the choice of software architect.
So everything is fine now?
No!
Still this approach is having multiple challenges. like
- Monitoring the multiple chunk of instance is really hard
- Deployment and other operational changes and iterations are really hard for multiple instances,
- Security and Governance for independent services are really complex to manage
- Data Analysis and data mining are the major challenges if we change the approach.
Still if we follow proper technology and design stack, we could face it even better by means of reliability and performance.
For monitoring, Implementing proper cluster management system and policies around it will make this possible.
For deployment and other operational works, implementing proper orchestration system and distributed system with centralized content management will make this possible
For Security and governance, Implementing Oauth with proper IAM, Key based inter service communication, Automatic security patching, distributed firewall with centralized control and mainly getting your service instances out of public network will make this possible
For Data analytics and Data mining, Implementing distributed data collectors with centralized control of analytic system.
Ultimately, with proper DevOps and Agile implementation we can totally avoid the conflicts and miscommunication between team members and teams, increasing productivity, real agility and efficiency of enterprises.
Of course, Service oriented architecture is not the ultimate evolution. So we have to be flexible so that we can adopt whatever the best practice comes in the future and we DevOps enthusiast will make sure of this agility.