Modern Architectures

13 MarchTechnology, Latest

Web Application Architecture is a framework that is comprised of the relationships and interactions between application components, such as middleware systems, user interfaces, and databases. In layman term, this is a pattern of interaction between web application components such as web server, database server, load balancer, etc.

The reason why it is imperative to have good web application architecture is because it is the blueprint for supporting future growth which may come from increased demand, future interoperability and enhanced reliability requirements. Through object-oriented programming, the organizational design of web application architecture defines precisely how an application will function.

As technology continues to evolve, so does web application architectures. One such trend is the use of and creation of service-oriented architecture. This is where most of the code for the entire application exists as services. In addition, each has its own HTTP API. As a result, one facet of the code can make a request to another part of the code–which may be running on a different server. Another trend is a single-page application. This is where web UI is presented through a rich JavaScript application. It then stays in the user’s browser over a variety of interactions. In terms of requests, it uses AJAX or WebSockets for performing asynchronous or synchronous requests to the web server without having to load the page.

Some modern architectures that are currently prevalent in the industry include:

  • Micro Services
  • Serverless Architectures
  • Single Page Application
  • Progressive Web Applications
  • API First-Design

Microservices Architecture

The “micro” implies for the small applications. That is occasionally true, but a better way to think about is that they should be only as big as needed to do one particular thing or solve a specific problem. Microservices architecture means the idea of developing software, where applications are structured as a collection of autonomous. According to Microsoft, “Microservices architectures need to be designed around business competences, not horizontal layers such as data access.” They interconnect with other microservices and outside users through relatively stable APIs to create a broader application. Therefore, the core functionality of an individual microservice can be upgraded without upsetting the rest of the system. It sequentially ties into how DevOps shops seek to run: If the specific functions of a broader application are segmented out into discrete, individually operating pieces of code, it is easier to live the DevOps refrain of CI/CD. Also, well-defined APIs make microservices easy to test automatically.

View Larger

How to build microservices?

  • Step 1: Start with a monolith If you do not have any users for your application, there are chances that the business requirements are going to change despite the fact you're building your MVP promptly. This is because of the nature of software development and the feedback cycle that needs to happen while you're identifying the critical business competencies that your system needs to offer. Microservices work well when you devise a good grip on the roles of the different services required by your system. Start by splitting the logic from your web UI and validate that it interacts with your backend through a RESTful API over HTTP.
  • Step 2: Organise your teams Until now, it would have felt that building microservices is typically a technical affair. All you need is to split a codebase in various services, figure out the right patterns to fail gracefully and recover from network issues, deal with data consistency, monitor service load, etc.
  • Step 3: Split the monolith to build the microservices architecture Now when you've recognized the boundaries of your services and figured out how you can change your teams to be more upright in the sense of capabilities, you can start separating your monolith to build microservices. Here are the key points:
    1. Keep communication among services simple with a restful API
    2. Divide your data structure
    3. Build your microservices architecture for failure
    4. Emphasize monitoring to ease microservices testing
    5. Embrace continuous delivery to reduce deployment friction

When should you go for a modern microservices architecture?

Here are some of the typical scenarios where you can consider going for the microservice architecture patterns:

  • Monolithic application migration because of improvements needed in scalability, manageability, skill, or delivery speed.
  • Re-platform a legacy application by converting the modules to microservices.
  • Rephrasing legacy application to the modern languages, technology stack to meet the requirements of the current business.
  • Distinct crosscutting services that are free in nature. For example, encryption services, authentication services, etc.
  • Independent business applications or services reused across multiple channels — for example, payment services, flight search services, customer profile services, notification services, etc.
  • Commonly used enterprise applications. For example, the time tracking app.

Serverless Architecture

Serverless has been attaining a lot of attention from the pros and the rookies in the tech industry. Serverless architecture aws has excited the architecture, from consultations to meetups to blog posts to nearly everywhere. Nonetheless, serverless is not about the hype, and it potentials the probability of ideal business implementations which sounds quite pleasant to the ears and probably light on the budget as well.

What is meant by Serverless?

Serverless means the cloud computing execution model where the cloud provider dynamically brings about the allocation and provisioning of servers. A serverless application works in stateless compute containers that are event-triggered, temporary, and fully managed by the cloud provider. Serverless applications are event-driven cloud-based systems where application development depends on a combination of third-party services, client-side logic , and cloud-hosted remote procedure calls (Functions as a Service).

View Larger

How to Develop Serverless Architecture?

Before starting the serverless architecture development process, the business case needs to be weighed, to justify the move. The serverless economics may be very compelling, but still need to be appraised in light of architectural investments previously made, and how it will serve pressing business requirements.

Blending and migration

Serverless computing is integrally a cloud-based phenomenon; the best place to start is looking at what cloud providers have to offer. Use container technology to assure the seamless transformation of code and applications between environments.

Security

To a great extent, serverless takes many security headaches off the table. Traditional IT architectures that provide relatively large attack surfaces such as the network, host operating systems, services, business logic, data and the user remarkably shrink in serverless settings. Still, even serverless environments needs diligence and vigilance. Therefore, security teams must be careful of the function code, what services can be accessed by the function, data misuse and access, and certain types of denial-of-service attacks. The cloud provider that is compering the function as a service is accountable for securing the underlying infrastructure."

Storage

Another area where the serverless computing shifts the dynamic is storage. Storage is typically the riskiest part of serverless. Cloud providers have a variety of storage options, some are advertised as 'serverless,' although you aren't limited to those. The scalability of serverless storage is a critical factor. It's important to remember that the data model and design influence the scalability of storage systems. So you need to pick both storage and data model that will suit your scalability expectations.

When should Serverless Architecture be considered?

Here are some of the areas where serverless architecture can be used

  • High dormancy background tasks like multimedia and data processing
  • Client-heavy applications where the maximum of the logic can be moved to the client
  • Applications with an unpredictable amount of server load
  • Fast-growing applications that should scale simultaneously and be able to change features rapidly
We'll continue our discussion on rest of the architectures in part 2 of the article
Technology, Modern Web Application, Modern Web Architectures, Booleans Daily