Posted on

Composable Architecture

Introduction

There has been a change in basic assumptions by which the software selections happen in an organization. Though principles, policies, and guidelines dictate the same, in most cases the following factors have a direct bearing in the selection of products, technologies, and development:

  • Existing skills within an organization
  • Availability of the chosen skill in the market
  • Protection of existing investment in infrastructure, IP, human resources
  • How the chosen product/technology deals with the existing IT landscape
  • And of course, other tangible benefits such as TCO, ROI, time to market, etc.

Let us get into the brass tacks of composable architecture. Every architecture is made up of domains and capabilities mapped to the domains. Each capability can be fulfilled by one or more solution components and vice versa.

Posted on

How AWS App Mesh Redefines Applications

For someone interested in knowing more about Amazon Web Services and its feature sets, it is appropriate to know about the AWS App Mesh and the diverse applications pertaining to it. That said, it is essential to take a note of the fact that this App Mesh is now available and provides seamless networking, especially at the application level. Put simply, the AWS App Mesh makes sure that diverse computing services across the online networks are connected, in order to communicate with each other. Moreover, the AWS App Mesh also makes room for a standardized communicative model that makes way for high application availability and end-to-end visibility.

More about AWS

For understanding how Amazon Web Services actually works in regard to the computing services, it is necessary to understand that a majority of these services have EC2 and Fargate as the backbones. Therefore, when services keep growing within a specific application, it becomes arduous for both the developer and users to locate errors. In addition to that, when applications fail, it also becomes difficult to reroute the traffic while maintaining the sanctity of the application module.

Posted on

The Micro-Hexagon Architectural Pattern

Although microservices solve many technical problems, it is time perhaps to conclude, after a few years from the launch date of this concept, that this architecture needs to be further improved, to provide a way to have a clearer vision of the functional components. That's why many architects now use DDD decomposition.

Another concept that has been put in place with DDD is event sourcing and CQRS. In fact, we do not deny the benefits of these implementations but it could also have other technical drawbacks which impact our architecture with more complex debts.