Software application architecture
- 1. By Tripti Anwita Software Application Architecture (Monolithic Vs SOA Vs Microservices Vs Serverless)
- 2. Importance of Software Architecture 4/8/2020TRIPTI ANWITA2 Creating a new product is all about risk. And choosing the right architecture is an essential step toward success. You want to build a product can scale, distribute, and helps you with the speed to market. Your development, testing, and production processes have to be Agile. You need to bring your idea to market fast. Then you have limited human capital resources. All this brings in complexity and pressure for architects and founders. Your choice can make or break your venture.
- 3. Monolithic Architecture 4/8/2020TRIPTI ANWITA3 In software engineering, a monolithic pattern refers to a single indivisible unit. The concept of monolithic software lies in different components of an application being combined into a single program on a single platform. Usually, a monolithic app consists of a database, client-side user interface, and server- side application. All the software’s parts are unified and all its functions are managed in one place.
- 4. Pros of a monolithic architecture 4/8/2020TRIPTI ANWITA4 Simpler development and deployment - There are lots of tools you can integrate to facilitate development. In addition, all actions are performed with one directory, which provides for easier deployment. With a monolithic core, developers don’t need to deploy changes or updates separately, as they can do it at once and save lots of time. Fewer cross-cutting concerns - Most applications are reliant on a great deal of cross-cutting concerns, such as audit trails, logging, rate limiting, etc. Monolithic apps incorporate these concerns much easier due to their single code base. It’s easier to hook up components to these concerns when everything runs in the same app. Better performance - If built properly, monolithic apps are usually more performant than microservice-based apps. An app with a microservices architecture might need to make 40 API calls to 40 different microservices to load each screen, for example, which obviously results in slower performance. Monolithic apps, in turn, allow faster communication between software components due to shared code and memory.
- 5. Cons of a monolithic architecture 4/8/2020TRIPTI ANWITA5 Codebase gets cumbersome over time - In the course of time, most products develop and increase in scope, and their structure becomes blurred. The code base starts to look really massive and becomes difficult to understand and modify, especially for new developers. It also gets harder to find side effects and dependencies. With a growing code base quality declines and the integrated development environment (IDE) gets overloaded. Difficult to adopt new technologies - If there’s a need to add some new technology to your app, developers may face barriers to adoption. Adding new technology means rewriting the whole application, which is costly and time- consuming. Limited agility - In monolithic apps, every small update requires a full redeployment. Thus, all developers have to wait until it’s done. When several teams are working on the same project, agility can be reduced greatly.
- 6. The bottom line about monolithic architecture 4/8/2020TRIPTI ANWITA6 The monolithic model isn’t outdated, and it still works great in some cases. Some giant companies like Etsy stay monolithic despite today’s popularity of microservices. Monolithic software architecture can be beneficial if your team is at the founding stage, you’re building an unproven product, and you have no experience with microservices. Monolithic is perfect for startups that need to get a product up and running as soon as possible. However, certain issues mentioned above come with the monolithic package.
- 7. SOA 4/8/2020TRIPTI ANWITA7 A service-oriented architecture (SOA) is a software architecture style that refers to an application composed of discrete and loosely coupled software agents that perform a required function. SOA has two main roles: a service provider and a service consumer. Both of these roles can be played by a software agent. The concept of SOA lies in the following: an application can be designed and built in a way that its modules are integrated seamlessly and can be easily reused.
- 8. 4/8/2020TRIPTI ANWITA8 SOA - four basic service types Business Services: Coarse-grained services that define core business operations. Represented through XML, Business Process Execution Language (BPEL), and others. Enterprise Services: Implement the functionality defined by business services. Mainly rely on application services and infrastructure services to fulfill business requests. Application Services: Fine-grained services that are confined to a specific application context. A dedicated user interface can directly invoke the services. Infrastructure Services: Implement non-functional tasks such as authentication, auditing, security, and logging. Can be invoked from either application services or enterprise services.
- 9. Pros of SOA 4/8/2020TRIPTI ANWITA9 Reusability of services - Due to the self-contained and loosely coupled nature of functional components in service-oriented applications, these components can be reused in multiple applications without influencing other services. Better maintainability - Since each software service is an independent unit, it’s easy to update and maintain it without hurting other services. For example, large enterprise apps can be managed easier when broken into services. Higher reliability - Services are easier to debug and test than are huge chunks of code like in the monolithic approach. This, in turn, makes SOA-based products more reliable. Parallel development - As a service-oriented architecture consists of layers, it advocates parallelism in the development process. Independent services can be developed in parallel and completed at the same time. Below, you can see how SOA app development is executed by several developers in parallel.
- 10. Cons of SOA 4/8/2020TRIPTI ANWITA10 The aggregation layer (SOA Bus) - The issue was the addition of the operational logic to the bus. As this layer got bigger and bigger with more and more components added to the system, so came the issues of system coupling. Complex management - The main drawback of a service-oriented architecture is its complexity. Each service has to ensure that messages are delivered in time. The number of these messages can be over a million at a time, making it a big challenge to manage all services. High investment costs - SOA development requires a great upfront investment of human resources, technology, and development. Extra overload - In SOA, all inputs are validated before one service interacts with another service. When using multiple services, this increases response time and decreases overall performance.
- 11. The bottom line about SOA 4/8/2020TRIPTI ANWITA11 The SOA approach is best suited for complex enterprise systems such as those for banks. A banking system is extremely hard to break into microservices. But a monolithic approach also isn’t good for a banking system as one part could hurt the whole app. The best solution is to use the SOA approach and organize complex apps into isolated independent services.
- 12. Microservice architecture 4/8/2020TRIPTI ANWITA12 Microservice is a type of service-oriented software architecture that focuses on building a series of autonomous components that make up an app. Unlike monolithic apps built as a single indivisible unit, microservice apps consist of multiple independent components that are glued together with APIs.
- 13. 4/8/2020TRIPTI ANWITA13 This architecture enabled a true polyglot deployment, where you can use different languages or frameworks to work together. So, the front end developers might be working with React, while the BackDeveloper are using C#, and the data team is working with Python. All the services can talk to one another and utilize the resources as needed. All the communication between the services in over ReST over HTTP. One of the best ways to configure all the service communication is via an API Proxy. This architecture also renders itself well suited for the cloud-native deployment. Done right, this architecture does help you in building cloud-native services. Most of the architects work with micro-services to move to a cloud-native platform.
- 14. Pros of microservices 4/8/2020TRIPTI ANWITA14 Easy to develop, test, and deploy - The biggest advantage of microservices over other architectures is that small single services can be built, tested, and deployed independently. Since a deployment unit is small, it facilitates and speeds up development and release. Besides, the release of one unit isn’t limited by the release of another unit that isn’t finished. And the last plus here is that the risks of deployment are reduced as developers deploy parts of the software, not the whole app. Increased agility - With microservices, several teams can work on their services independently and quickly. Each individual part of an application can be built independently due to the decoupling of microservice components. For example, you may have a team of 100 people working on the whole app (like in the monolithic approach), or you can have 10 teams of 10 people developing different services for the app. Let’s imagine this visually. Increased agility allows developers to update system components without bringing down the application. Moreover, agility provides a safer deployment process and improved uptime. New features can be added as needed without waiting for the entire app to launch. Ability to scale horizontally - Vertical scaling (running the same software but on bigger machines) can be limited by the capacity of each service. But horizontal scaling (creating more services in the same pool) isn’t limited and can run dynamically with microservices. Furthermore, horizontal scaling can be completely automated.
- 15. Cons of microservices 4/8/2020TRIPTI ANWITA15 Complexity - The biggest disadvantage of microservices lies in their complexity. Splitting an application into independent microservices entails more artifacts to manage. This type of architecture requires careful planning, enormous effort, team resources, and skills. The reasons for high complexity are the following: Increased demand for automation, as every service should be tested and monitored Available tools don’t work with service dependencies Data consistency and transaction management becomes harder as each service has a database Security concerns - In a microservices application, each functionality that communicates externally via an API increases the chance of attacks. These attacks can happen only if proper security measurements aren’t implemented when building an app. Different programming languages - The ability to choose different programming languages is two sides of the same coin. Using different languages make deployment more difficult. In addition, it’s harder to switch programmers between development phases when each service is written in a different language.
- 16. Major Differences Between Microservices and SOA 4/8/2020TRIPTI ANWITA16 Service Granularity: Service components within a microservices architecture are generally single-purpose services that do one thing really, really well. With SOA, service components can range in size anywhere from small application services to very large enterprise services. In fact, it is common to have a service component within SOA represented by a large product or even a subsystem. Component Sharing: Component sharing is one of the core tenets of SOA. As a matter of fact, component sharing is what enterprise services are all about. SOA enhances component sharing, whereas MSA tries to minimize on sharing through “bounded context.” A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies. As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than MSA. Middleware vs API layer: The microservices architecture pattern typically has what is known as an API layer, whereas SOA has a messaging middleware component. The messaging middleware in SOA offers a host of additional capabilities not found in MSA, including mediation and routing, message enhancement, message, and protocol transformation. MSA has an API layer between services and service consumers.
- 17. Major Differences Between Microservices and SOA 4/8/2020TRIPTI ANWITA17 Remote services: SOA architectures rely on messaging (AMQP, MSMQ) and SOAP as primary remote access protocols. Most MSAs rely on two protocols – REST and simple messaging (JMS, MSMQ), and the protocol found in MSA is usually homogeneous. Heterogeneous interoperability: SOA promotes the propagation of multiple heterogeneous protocols through its messaging middleware component. MSA attempts to simplify the architecture pattern by reducing the number of choices for integration. If you would like to integrate several systems using different protocols in a heterogeneous environment, you need to consider SOA. If all your services could be exposed and accessed through the same remote access protocol, then MSA is a better option.
- 18. The bottom line for Microservices 4/8/2020TRIPTI ANWITA18 Microservices are good, but not for all types of apps. This pattern works great for evolving applications and complex systems. Consider choosing a microservices architecture when you have multiple experienced teams and when the app is complex enough to break it into services. When an application is large and needs to be flexible and scalable, microservices are beneficial.
- 19. Serverless architecture 4/8/2020TRIPTI ANWITA19 Serverless architecture is a cloud computing approach to building and running apps and services without the need for infrastructure management. In serverless apps, code execution is managed by a server, allowing developers to deploy code without worrying about server maintenance and provision. In fact, serverless doesn’t mean “no server.” The application is still running on servers, but a third-party cloud service like AWS takes full responsibility for these servers. A serverless architecture eliminates the need for extra resources, application scaling, server maintenance, and database and storage systems.
- 20. Serverless architecture 4/8/2020TRIPTI ANWITA20 The serverless architecture incorporates two concepts: FaaS ( Function as a Service) – a cloud computing model which allows developers to upload pieces of functionality to the cloud and let these pieces be executed independently BaaS ( Backend as a Service) – a cloud computing model which allows developers to outsource backend aspects (database management, cloud storage, hosting, user authentication, etc.) and write and maintain only the frontend part When using a serverless architecture, developers can focus on the product itself without worrying about server management or execution environments. This allows developers to focus on developing products with high reliability and scalability.
- 21. Top Serverless Computing Providers 4/8/2020TRIPTI ANWITA21
- 22. Pros of a serverless architecture 4/8/2020TRIPTI ANWITA22 Easy to deploy - In serverless apps, developers don’t need to worry about infrastructure. This allows them to focus on the code itself. Serverless architecture allows you to spin up an app extremely fast, as deployment takes only hours or days (compared to days or weeks with a traditional approach). Lower costs - Going serverless reduces costs. Since you don’t need to handle databases, some logic, and servers, you can not only create higher quality code but also cut expenses. When using a serverless model, you’re only charged for the CPU cycles and memory you actually use. Enhanced scalability - Many business owners want their apps to become influential and scalable like Google or Facebook. Serverless computing makes scaling automatic and seamless. Your app will automatically scale as your load or user base increases without affecting performance. Serverless apps can handle a huge number of requests, whereas a traditional app will be overwhelmed by a sudden increase in requests.
- 23. Cons of a serverless architecture 4/8/2020TRIPTI ANWITA23 Vendor lock-in - It describes a situation when you give a vendor full control of your operations. As a result, changes to business logic are limited and migration from one vendor to another might be challenging. Not for long-term tasks - A serverless model isn’t suitable for long-term operations. Serverless apps are good for short real-time processes, but if a task takes more than five minutes, a serverless app will need additional FaaS functionality. Serverless software architecture is beneficial for accomplishing one-time tasks and auxiliary processes. It works great for client-heavy apps and apps that are growing fast and need to scale limitlessly.
- 25. References 4/8/2020TRIPTI ANWITA25 https://rubygarage.org/blog/monolith-soa- microservices-serverless https://dzone.com/articles/microservices-vs-soa- whats-the-difference https://medium.com/@saad_66516/monolithic-vs- soa-vs-microservices-how-to-choose-your- application-architecture-1a33108d1469 https://www.edureka.co/blog/microservices-vs- soa/