DEV Community: Ashan Fernando

Composable Software Architectures are Trending: Here’s Why

Ashan Fernando — Tue, 19 Mar 2024 11:11:18 +0000

The progression from monolithic applications to composable architecture marks a significant leap in building highly scalable and maintainable software applications. This evolution crossed different milestones in its path.

The Era of Monolithic Applications

Historically, software systems were predominantly monolithic. In these systems, various components, including the user interface, business logic, and data access layers, are tightly integrated within a single codebase. While this approach was straightforward and productive initially, it inevitably led to challenges as applications grew in complexity.

Even a minor modification to the application could necessitate rebuilding, testing, and redeploying the entire application, introducing inefficiency. Additionally, developer efficiency decreases as many developers have to collaborate and handle a broader cognitive load to identify the areas of change and their impact.

The Modular Monolith

Before the widespread adoption of microservices and micro frontends, the modular monolith architectural style emerged as a middle ground between the traditional monolith and the fully distributed microservices.

This approach aims to retain the operational simplicity of the monolith while introducing a level of modularity and separation of concerns typically associated with Microservices. It draws clear boundaries around modules, making development and testing more granular, reducing the cognitive load for development, and thus improving overall productivity.

Yet, the fundamental challenges of a large code base still exist, impacting developer collaboration and efficient use of resources to run the application.

Shift Toward Microservices and Micro Frontends

The advent of Microservices marked a paradigm shift to address many challenges of monolithic architectures at scale. Microservices architecture enabled independent development, testing, and deployment by breaking down applications into smaller, loosely coupled services, each responsible for a specific function and communicating through well-defined interfaces.

Building on the principles of Microservices, the concept of Micro frontends emerged to address similar challenges in the frontend landscape. Microfrontends extend the Microservices paradigm to the frontend, breaking down monolithic frontend codebases into smaller, more manageable pieces.

However, there is a fundamental difference between Microservices and Microfrontends. Microservices are distributed systems where each service has an end-to-end lifecycle and complete autonomy in development and operations. Therefore, it is recommended that each Microservice run on its own process (runtime isolation) and databases (data isolation) and has its own codebase (code isolation), minimizing dependencies across development teams, resulting in less reuse and collaboration.

On the other hand, Micro frontends need a significant level of component reuse to keep UI consistent. It requires either run-time or build-time (preferred) integration before running in the browser.

Microservices and Micro frontends are not suitable for everyone. A startup or a small development team may find it difficult and counter-productive to adapt these architectural styles as they come with overheads in setting up projects and managing operations. Therefore, the cost of adapting these architectures makes sense beyond a certain scale.

Introducing Purely Composable Architecture

Composability involves creating software applications from independent, reusable components, each encapsulating its dependencies and distinct functionality. Then, these components (building blocks) can be combined to build complex applications. It’s a fundamental difference to the way we used to develop software applications.

Since components are smaller, reusable building blocks, the context of change becomes the scope of the components that can be modified and tested independently. The main gap in implementing composable architecture in the past is not having robust tooling to support it. And since some changes may cut across multiple components, robust tooling that aids in modifying components in bulk and testing the dependency chain is required.

The following diagram showcases how bit shows the dependency graph of modified components and their dependents.

And the beauty of this approach is that since it’s so fundamental, you can use it with other architectural styles to address some of their weaknesses. Following are some examples.

You can use components to build your Microservices so that you can start collaborating between teams and share components.
Use app as the shell component to build your Micro frontends, using a remote scope for each team.
Create an Env for each Microservice so that the technology used in each Microservice is independent of one another.

And, since each component has its documentation, clear interfaces, tests, and previews and share these in bit.cloud, collaboration increases at scale across codebases and teams.

And there are many other benefits of implementing a composable architecture;

Enhanced Flexibility: Architecture becomes flexible when adopting different styles and patterns.
Scalability of the development team: Individual components can be scaled as needed, allowing for more efficient resource utilization.
Maintainability: The modular nature of composable architectures simplifies maintenance and updates, as changes are localized to specific components.
Innovation and Speed: Reusable components accelerate development cycles and foster innovation by enabling teams to leverage existing functionalities for new applications and collaborate better.
Better dependency management: Consider a scenario where a UI component library is used across multiple projects within an organization. Bit can manage these components’ dependencies, ensuring that updates do not break functionality in any projects relying on the library.

Summary

The evolution from monolithic applications to composable architectures is redefining the standards for software development. With the support of advanced tools like Bit, the future of software development is set to be more flexible, efficient, and aligned with the dynamic needs of businesses.

As we move forward, composable architectures will undoubtedly continue to shape the future of software development, marking a significant shift towards more adaptable and resilient software systems.

Deployment Strategies for Auto-Scaling and Load Balancing EC2 Instances in AWS

Ashan Fernando — Mon, 26 Feb 2018 15:03:48 +0000

Scalability is one of the most important aspects to consider for modern web application deployments. With the advancement of Cloud technologies, it has never been easier to design solutions for scalability. The elasticity of Cloud provides the basic foundation and flexibility to design practical solutions.

Using AWS, it is possible to provision EC2 instances and pay only for the time of usage and also allowing to automate the scaling out (Creating more instances) for the demand automatically, with tools like Auto Scaling Configurations, Launch Configurations, Load Balancers, Amazon Machine Images (AMIs) and more.

However, there are various factors that involve in building a reliable and efficient scaling platform for your application deployments which is worth to consider. Therefore it is required to design the auto-scaling appropriately to address the following,

Scaling efficiently on demand (reducing new instance provisioning time).
New deployment support with near zero downtime.
Rollback support.
Disaster recovery.

Auto-Scaling and Load Balancing Tools in AWS

There are several fundamental services required for autoscaling and load balancing deployments. Most of these services are readily available as managed services from AWS.

Load Balancer - Requires to balance the load coming from clients and fairly distribute to the healthy EC2 instances. It also requires to identify unhealthy instances and stop sending the traffic. In AWS, there are multiple types of Load Balancers available (Classic Load Balancer, Application Load Balancer & Network Load Balancer) which can be used for different purposes. However, Application Load Balancer is commonly used for general Web Applications.
Auto-Scaling Tools - These tools are needed to identify the limitations of existing capacity and trigger provisioning of new instances (Scale-out) and also to terminate instances (Scale-in) when the load is less. AWS provides a combination of tools to support this including CloudWatch (To monitor), Auto-Scaling Configurations, Launch Configurations (Instructions to bootstrap new instance).

Using Custom AMIs

One of the common approaches is to create an AWS EC2 instance with the required operating system and application inside and create a Custom AMI (Virtual Machine Image). This allows defining the AMI reference in AWS EC2 Launch Configuration to instruct AWS auto-scaling tools to bootstrap new instances using the custom AMI.

Pros

Straightforward to configure the provisioning rules.
Easy to rollback and update new instances (AWS provides support for rolling updates).
Support for deploying a large number of instances.
Relatively fast bootstrap process.

Cons

Requires to have a relatively complex build process and required to build new AMIs for each update.

However, it is also possible to have a Custom AMI and do minor configurations upon the EC2 instance bootstrap process.

Dynamically Bootstrap EC2 Instances

In this approach, it is possible to use a base AMI provided by Amazon which contains only the operating system and general software. There are several approaches to implement dynamically bootstrapping EC2 instances for an application deployment.

Use a Base AMI from Amazon and bootstraps its application when the instance is starting using the AWS Launch Configurations.
Create a Custom AMI that is capable of loading a specified version of the application upon bootstrap.
It is also possible to use a base Amazon AMI with Docker where the container image is pulled or built upon bootstrapping of the instance.

Pros

Not required to keep AMIs for each deployment.
Base AMI software patching can be done independently from the application.
Straightforward to configure the provisioning rules.
Build process and deployment is straightforward (Without the need for the AMI build).

Cons

For large applications, bootstrapping can take more time causing problems for spike loads (Taking too much time to provision and handle the excess load).
Supporting rollback would be difficult unless following an approach to keep track of bootstrap code with deployment version (e.g Store each deployment in S3 and bootstrap process will retrieve the relevant version).

However, using Docker can solve some of the problems of deployment versioning and rollback which requires to containerize the applications and have a unique docker build process.

The Importance of Capacity Planning for EBS Volumes in AWS

Ashan Fernando — Thu, 01 Feb 2018 19:06:07 +0000

Provisioning an EC2 instance with an EBS volume for your applications is quite straightforward in AWS. However, have you ever thought whether you are provisioning either under or over the required amount of capacity for Storage?

This is one of the main places where over provisioning happens. Its common to provision higher amount of capacity or throughput just to be on the safe side but finally ending up in problems when application workload changes. Therefore doing a proper capacity planning considering different factors like volume type, size, throughput, latency, automation, and costs are really important.

In addition, there are other factors such as selecting the taking snapshots, pre-warming & etc. which also affects AWS EBS performance that also needs to be considered for capacity planning.

One of the main challenges applications faces with poor capacity planning is in handling peak application loads as well as when handling failures. With the support of automation tools available in AWS and knowing the limitations, it is possible to plan for these situations without over-provisioning the storage which costs more.

Storage Volume Type and Size

This is one of the main areas where wrong selections are made since AWS EBS provides multiple options for underlying physical storage device types and storage capacity. In the past, it was important to plan for the storage size since it was required to restart the EC2 instance after increasing the storage size which can result in a downtime. With the current generation of AWS EBS Volumes, you can increase the size, change the volume type of IOPS without detaching it. It is possible to do the same for detached volumes as well.

Another important action you can take is to automate the associated volume modifications using CloudFormation, AWS CLI or using AWS SDKs so that you can provision the required configuration optimally and when it is needed.

Storage IOPS

It is equally important to do plan on the required throughput. Most of the time I see many EC2 configurations go ahead with the default settings in selecting general purpose SSD which is alright unless you know what you are doing. However, there are costs benefits in selecting HDD storage over SSD for several sequential access scenarios or non-trivial workloads which needs to be considered while planning the throughput. On the other hand, if you are dealing with applications with high-performance requirements and IOPS, it is important to do several load testing for the application forehand and understand the IOPS requirements for different nature of workloads so that adequate automation and capacity can be provisioned to efficiently run the applications.

Storage Latency

This is one of the areas where many forget about considering especially for high-performance applications. One of the important aspects of managing latency is to manage the queue length which depends on the number of pending I/Os for an EBS device. You need to consider this and plan the queue considerations based on the latency and I/O size.

Another area many are unaware of is that upon creation of an EBS volume from a snapshot and try to access it for the first time can cause unexpected latencies. For an application that requires performance starting from the first read needs to be Pre-Warmed by hitting each block before running the application in production which can be achieved by initializing the EBS.

Automation

This is a very crucial area which you should be focussing on. Knowing the limitations and capabilities for automating EBS capacity and provisioning possibilities can save lots of money due to over and under provisioning of EBS volumes.

One of the places you can start in figuring out the automation capabilities is to go through the features in AWS EBS Volume in web console and then understand the underlying configurations which you can automate or require manual interactions. In addition looking at the matrices in CloudWatch for EBS also provides a great insight in possibilities to monitor and trigger for automation which might require writing a custom logic using AWS EBS SDK in a Lambda function or period monitor and provisioning triggers.

Costs

Provisioning extreme limits with the highest throughput available is something anyone can do. It takes careful planning and effort to identify the required capacity limitations and provision accordingly. This is the most important area you need to carefully evaluate for AWS EBS capacity planning because finally, it boils down to the application performance and how efficiently the storage is utilized for the application reducing the costs.

I frequently use AWS Calculator to come up with rough estimates after selecting the EBS volume size, type and IOPS configurations. It is also important to understand that the AWS costs changes from region to region and also based on the Usage. So selecting right region while having the necessary configuration for automated tasks can save you a considerable amount of money if done properly. This includes scheduling snapshots on required time frames, increasing storage size with predictive analysis while affecting the changes at the right time frames.

AWS Storage Costs

Ashan Fernando — Tue, 09 Jan 2018 09:58:47 +0000

Amazon Web Services (AWS) provides various storage options for backup, archiving, and disaster recovery as well as for block, file, and object storage. These low-cost storage options provide high availability and durability for different use cases (more details from the official documentation). Each of these storage options differs from each other providing unique offerings. It is important not only to understand the appropriate use cases for storage, but also the underlying cost structure.

Total Cost of Ownership of storage will also differ depending on region and the approach of storage management. It is important to provision the required amount and scale up once required. There are third-party storage management tools which provide automated options with different AWS cost structures. For example, third-party solutions like NetApp's ONTAP cloud provide enhanced features for AWS storage, for example, automating workloads, disaster recovery, devops, file sharing, database management, and more.

To monitor the storage is consumed, there are various tools available, including AWS internal ones as well as third-party tools such as AWS Billing Console, Bills, Cost Explorer or Third Party Storage Management tools with custom monitoring support.

Storage Cost Calculation

When estimating storage costs, it requires looking at the use case from different dimensions depending on the specific storage option. One or more of these dimensions are required to be considered while calculating storage costs. In general, the dimensions we can look into can be divided as follows.

Storage capacity provisioned/used
Data transfer capacity
Data transfer rate
Replication factor
Access patterns

Note: AWS also provides cost savings based on AWS Free Tier limits. You can track your AWS Free Tier usage to stay under the free tier limits.

Amazon Simple Storage Service (S3)

AWS S3 is a scalable and highly durable object storage service in the cloud with following pricing components.

Storage (per GB per month)
Data transfer in or out (per GB per month)
Requests (per thousand requests per month)
Data Transfer In and Out (for S3 Transfer Acceleration)

Amazon Glacier

Low-cost, highly durable archive storage in the cloud with following pricing components.

Storage (per GB per month)
Data transfer out (per GB per month)
Requests (per thousand Upload and Retrieval requests per month)

Amazon Elastic File System (EFS)

EFS is a scalable network file storage for Amazon EC2 instances where you only pay for the amount of storage used in your file system.

Amazon Elastic Block Store (EBS)

EBS provides Block storage volumes for Amazon EC2 instances with following pricing components.

Provisioned storage
I/O requests
Snapshot storage

Amazon EC2 Instance Storage

Temporary block storage volumes for Amazon EC2 instances with no additional charge for data storage on local instance store volumes. However, data transfers across regions and Availability Zone incur data transfer charges.

AWS Storage Gateway

AWS Storage Gateway is an on-premises storage appliance that integrates with cloud storage with following pricing components.

Gateway usage (per gateway per month)
Snapshot storage usage (per GB per month)
Volume storage usage (per GB per month)
Virtual tape library/shelf storage (per GB per month)
Retrieval from virtual tape shelf (per GB)
Data transfer out (per GB per month)

AWS Snowball

Snowball Data transportation mechanism for large amounts of data to and from the cloud with following pricing components.

Service fee (per job)
Extra day charges
Data transfer

AWS CloudFront

Global content delivery network (CDN) with following pricing components.

Regional data transfer out (per GB)
Number of requests (per 10,000)

Estimate and Monitor Usage and Costs

You can use the AWS Cost Calculator to estimate the storage costs. You only need to enter the approximate values and the calculator does the rest. It is also important to understand that the storage costs vary by the AWS Region.

AWS Billing and Cost Management dashboard provide rich set of features to monitor Usage costs. Using the dashboard, you can check various graphs that show different breakdowns of your AWS usage as well as the last month, month-to-date, and month-end forecasted costs appear below.

You can use Cost Allocation Tags to further drill down and filter the costs. AWS also generates Cost Allocation Tags, containing resource creator information, that is automatically applied to the resources provisioned.

AWS Cost Explorer is another tool that comes in the Billing dashboard. You can use it to view costs data up to the last 13 months and also forecast how much you are likely to spend in the next three months with various filters.

In addition, you can set up budgets and notify the right people when a threshold exceeds by sending notifications via email or publishing notifications to your SNS topic.

5 Things You Didn't Know about Enterprise Cloud Storage

Ashan Fernando — Wed, 03 Jan 2018 03:38:10 +0000

With the advancement of cloud technologies, many enterprises moving to the cloud. This is mainly due to reduced total cost of ownership. The cloud is also becoming the technology innovation center for enterprises providing cutting edge technology influencing the architectures of enterprise systems. At the heart of enterprises, cloud storage and compute takes a major role. You can find a range of tools and technologies, such as AWS Storage Gateway, Microsoft Azure StorSimple, NetApp ONTAP Cloud, etc. to manage enterprise cloud storage and compute. This article focuses on storage technologies that help to enhance their enterprise systems.

#1 Elasticity for Disk Storage with adjustable throughput and physical storage type selection

If you have been using cloud compute services such as Amazon EC2, Microsoft Azure Virtual Machines or Google App Engine before, you have already used block storage services. In the past it was needed to shutdown or restart the virtual machine to increase the volume size. Now cloud providers are making it possible to increase the volume size, adjust performance, or change the volume type while the volume is in use. You can continue to use your application while the change takes effect. AWS has recently introduced this feature while other cloud providers will soon follow the trend. This allows you to provision only the required amount of storage for your enterprise systems and increase it on demand (manually or automatically) paying only for what you use reduces the costs even further.

Cloud block storage not only allows you to adjust the disk throughput (Input Outputs per Second - IOPS) but also allows to choose the right storage technology for your enterprise application workloads. For example, you are able to select the storage technologies such as SSD, Magnetic Disks (Throughput Optimized, Cold Storage). To compare the Disk Storage Options across the popular public cloud providers, refer the following links.

Amazon Elastic Block Storage Volume Types
Azure Disk Storage
Google Cloud Platform Storage Options

#2 Encryption at Rest

Today, almost all the popular public cloud providers allow to encrypt the disk storage to meet different compliance needs for enterprises. Cloud providers such as Google Cloud Platform, provides encryption by default while others provide it as an option to select based on the enterprise storage compliance requirements.

#3 Multi-Level Storage Redundancy

In the Cloud, the level of redundancy for storage comes with the type of the Storage we are using. For example disk storage provides redundancy by replication within the same data center or across multiple datacenters which are physically closer by connecting with low latency fiber optic networks.

When you use shared disk storage across multiple virtual machines, cloud providers like AWS (Elastic File System) allows the storage to be replicated across physically distant data centers allowing high availability and fault tolerance supporting disaster recovery.

For object storage services such as AWS S3, Azure Blob Storage and Google Cloud Storage, redundancy goes further deep by allowing multiple replications across several data centers as well as to replicate data across different geographical regions.

#4 Virtually Infinite Storage

Depending the storage type there are several limitations for file sizes, single storage size, maximum throughput & etc. Depending on the storage requirements, you should be able to select the best storage options that scales with your workloads. However, you should be able to provision multiple instances of the storage, virtually allowing infinite storage capacity for your enterprise workloads.

#5 Different Consistency Models

Cloud storage options come with different consistency models. It is mainly due to the level of redundancy these storage solutions provide. Depending on the storage type in use, your enterprise application required to be designed to support these consistency models. Two common consistency models Cloud Storage provides,

With strong consistency your application can expect once a record is written to the storage, subsequent read requests will get the latest update. However, with eventual subsequent reads after a write might retrieve the old object or the new object based on the replication lag. For a properly designed application this will provide better performance with high durability (With replication) since the underlying storage system doesn't wait for the reads to be retrieved while a replication happens.