DEV Community: Sowmen Rahman

When should you cache your APIs?

Sowmen Rahman — Sun, 05 May 2024 13:51:46 +0000

What is caching?

Caching is a mechanism to temporarily hold on to data returned over the network to end-user devices. There are multiple ways to implement caching, out of which the principal divisions are: client-side and server-side.

Client-side caching

This is a procedure used to cache data responses from servers on the end-user’s devices. This can generally be configured into the REST API clients that are used to fetch API responses. Caching rules are configured and built into the REST API clients themselves, so the responsibility to cache and invalidate the cache rests totally on the frontend application. This method of caching is quite painless if you’re starting out on caching for some backend platforms where you’re not too bothered about maintaining the software at scale. In fact, you’ll mostly see developers prioritising using client-side caching when starting out on small/hobby projects or at small companies (mainly bootstrapping companies).

Server-side caching

Caching methods deployed on your server are commonly known as server-side caching techniques. This means clients don't need to cache API responses on their end. Without a cache, an API user would make a round trip through all the functions and middlewares attached to an API controller and ultimately return the response of the controller. With caching enabled, the round-trip would be intercepted and the response stored by a cache would be returned instead, thus reducing the API latency.

Cache Hit Ratio

When a cache encounters a request by a user for the first time, it checks to determine if the key for this certain request exists in it's database. If it does, this is termed as a cache hit. Otherwise, it is a cache miss. The cache hit ratio is defined as:

This hit ratio is crucial for determining the efficiency of the cache server or caching logic, and is one of the most important factors you should consider when deploying a cache in front of your backend stack.

When should you cache your APIs?

Now let’s assume you’re a software engineer currently managing the backend of a medium-scale company. The average load of users isn’t too high, perhaps 7000-8000 users daily (in the current age of a software-driven world, we can agree that this scale is somewhat of medium or medium-large type).

Given that you’re a backend engineer, chances are you’ve already faced these scenarios or at least are aware of some of the keywords in the following points:

Request has timed out after 5000 ms
Connection timed out, maxContentLength size of -1 exceeded
Client exceeds API rate limiting quota (Error code 429)

These are some of the markers that indicate it’s time to start using caching techniques. Caching reduces load on the main API servers by diverting requests to a cache storage.

Today because of the importance of benefits caching brings to a software platform, there are many software implementations of cache database available, most of which are open-source and easy to deploy. The popular ones are Redis, Memcached, Varnish, etc. Popular cloud service providers like AWS, GCP, Azure, etc. provide their own dedicated caching services. However if you plan to use them, make sure to configure the storage & tiering options carefully, or you might end up racking up a huge bill.

Caching is a brilliant technique to reduce server load but we often fail to recognise where and when it is needed. Let’s look at a few cases where it makes the most sense to use caching (server-side).

Read-intensive data endpoints

API endpoints that are read-intensive benefit the most from having a cache layer. Imagine that you want to fetch the details of a user profile in your social media app. Generally, API endpoints that fetch user information do not return data that keep varying within seconds. Use caching on this type of API endpoints.

Cache expiry manipulation

Caching can be done variably with respect to expiry duration. Some endpoint return data that is expected to change over short durations i.e. a few seconds, while others may return data that does not change in hours or even days. Analysing the API stats via logging, metric aggregation and the underlying data type will give you an idea of what the expiry of cache on different endpoints should be.

Cache as a request idempotence guarantor

API request idempotence is important for endpoints that handle interactions that should not be repeated accidentally. A good example is an API endpoint that handles payment transactions; you certainly don’t want to pay twice for a single order. And while having separate middlewares for handling API idempotence is great, a cache layer can also help with the same objective. Simply set the cache key of the request equal to the idempotence key, you’ll be good to go! Although using caching on POST/PATCH/PUT/DELETE routes seems like an anti-pattern, I wouldn’t complain if it simplifies certain tasks.

Database caching

Remember that if you’re working in a resource-constrained environment or in one where you want to cut costs down to the minimum value possible, using in-built database caching can work as a great alternative. Of course, it requires working with the API of the database ORM that you’ve used in your project.

Reducing metered third-party API calls

Your APIs can sometimes reference data from third-party APIs. Most likely than not, these third party APIs will be metered in costs. Caching the data of these metered APIs will significantly help in controlling the costs and the latency of calling the external services.

Distributed applications

Many distributed backend use-cases can benefit from having a warmed up cache for certain data in order to lower API response times. Let’s consider an app's chat system. For each conversation you have in the app, you’d store a copy of the N most recent messages in the cache so that you don’t have to query the primary database on every user entry into the chat window. The system benefits largely if the caching action is performed on every new message received as it bypasses the need to fetch messages from the persistence layer frequently. This helps reduce the session load on a database, which is awesome!

Cache key generation

When it comes to constructing your cache keys, try to get creative with its generator functions. You should avoid including all your headers, query and path parameters, and only include those that are most likely to change when making requests. This is due to the fact that a single API request on the same endpoint can return different data based on what parameters were passed along with the request.

Cache servers as rate limiters

Cache storages can be used as API rate limiters. In cases where you'd like to control how many requests your backend can process in a single interval, generally per second (/s), a cache store can track the number of endpoint requests against a user token or user ID, and restrict them from accessing that endpoint till the timer resets. It is important to mention that the frontend should implement exponential backoff policy for API requests, otherwise the server load on the cache storage tends to increase rapidly.

Conclusion

Caching is a very interesting subject, one which can serve a bunch of other useful scenarios (like the ones we've seen above) based on the same theoretical principals of caching requests. While it can improve the system performance of backends, it is worthwhile to note that it can produce erratic data towards end-users if the configuration isn't set correctly. Cache invalidation must be done correctly and manual invalidations may also be employed as the use-cases require, in order to ensure a seamless experience for the end-users.

I built an open source app where you make friends by helping them

Sowmen Rahman — Fri, 09 Jul 2021 06:52:27 +0000

Through this post, I shall be introducing you to the making of and showcasing my open source app HelpingHand and also talk about the brief journey of the HarperDB2021 hackathon from my perspective.

WebApp link: https://helpinghand.sowmenrahman.tech

THE IDEA

HelpingHand is an open source app that was built to serve exactly one purpose:
To help people who are in need of it. Every app user signs up on the app platform and then can find themselves open to helping people from various posts that the people have earlier made. This person can then reach out to these people if they feel that the post describes a problem that he/she/they can solve.

But there's a catch, if you're reaching out to a person you've never interacted before, both of your identities are kept secret, unless the post shares finds you useful and decides to make you his/her/their friend. In this way, nobody can know much about the person they are helping, unless both sides cooperate together.

When a user decides to make another user their friend, they can then view their posts either help seeking posts or social posts and chat with them on the context of the post. This is basicall what HelpingHand is. You can think of HelpingHand as a cut down version of StackOverflow, but users are anonymous until both users are ready.

WHY THIS IDEA?

Ever since I was a child, I have always wanted to help people. So I guess the idea for this project naturally sprung from the urge of wanting to help people, no matter how small the contribution might be. The idea might not be that much of a good one, but I really wanted to participate in a hackathon, and this was a golden opportunity for me to showcase my skills.

TECHNOLOGIES

Frontend - React.js
Backend - HarperDB integrated REST API
Hosting - Vercel
Version Control - GitHub

HRN STACK?

If you're confused after reading the title of this post, don't question yourself because it seems like that at first. HRN would stand for HarperDB, React and Node.js.
Now I'm pretty certain everyone's looking for the 'E' in the stack, but there isn't one.

Let me give you a little backstory to why I skipped the server for this hackathon. Although this hackathon ran for a decent 30 days, I built this app on just over 7 days starting on 24th June. As I had too much academic stress from my university, I realized building both the backend and the frontend won't cut it before the deadline. Fortunately enough, HarperDB came to the rescue.

Using it's awesome SQL/NoSQL integrated REST API, I was able to build the backend without needing an Express or HAPI server like I'd generally need. Don't get me wrong, this really isn't the best way of doing this, but it was the only way if I wanted to finish on time, considering the features I had planned.

PROJECT FEATURES

Authentication

Users signup as direct database users and communicate directly without the meddling of any server in between. However, this also means that people will have to create usernames that abide with the authentication rules provided by HarperDB, and it also makes the process of making batch read and writes more difficult as everything is done on the client-end. It's not ideal, I know.

Login page

Signup page

Post sharing

Users are able to write posts and ask for help on the app. People can respond to these posts if they want to help them solve the problem. Posts can be of help type and social type. Only people you're friends with can see the social posts.

Searching

The top searchbar can be used to search for posts. Users may search targeting tags, title or description for posts.

Messaging

The core of the app relies on the ability to chat with people and communicate solutions for a certain type of problem. Users are able to chat with each other accordingly, but identities are kept hidden until one is satisfied with the help he/she is getting from the other person.

User view for public posts

Before a user messages a person for help response

After a user messages a person who needs help

After this, the help seeker can decide to reply or not as he wishes.

Notifications

The app also has minor notification support for when someone adds you as a friend or sends you a message. Currently, the notification system is not based on a websocket or external webhook server, and only updates on page refreshes, but these are all problems that can be mitigated with time, more on that on the roadmap talk that follows!

Mobile-friendly and responsive layout

Thanks to some very handy breakpoint hooks and responsive layout binding, I was able to make this website fully mobile responsive.

PROJECT ROADMAP

As you may have realized, the project is far from completion (the fact that it's somehow working with only a week of work is amazing to me, all thanks to HarperDB). I am outlining some of the more important tasks for this project. These are however not arranged in any specific order, but however among all other things, I am seriously considering refactoring as the first priority. The tasks are

Refactor code (A LOT)
Implement clean architecture (this was a primary target, but got cut short)
Enable persistence for rest of the reducers, currently only auth reducer has persistence enabled)
Reduce client-side manipulation code, implement backend code for auth, and other GET and POST operations in an Express.js server
Implement support for adding custom media to posts
Implement websockets and mail support(depends on the server implementation)
PWA (progressive web-app)

CONTRIBUTION

I invite the community to collaborate on this open-source project, as I'll not be discarding the project after the hackathon. I shall be making changes to the UI and building the server as soon as I am able.

CHALLENGES

Working with HarperDB was a very unique experience as I could manipulate the database using both SQL and NoSQL languages. The main challenge I had faced was really the time constraint compared to the project's goal weightage since I started very late. One other thing I noticed about HarperDB was that it'd not let me run nested SQL queries, it always ended up with some error I couldn't solve. However, I managed to find alternatives anyhow. Working on this project made me realize my strengths and weakness specially considering database modelling and querying.

Understanding SOLID: Dependency Inversion Principle

Sowmen Rahman — Sun, 20 Jun 2021 00:22:34 +0000

What is the dependency inversion principle?

The dependency inversion principle is one of the standard guiding rules of software design and development to ensure component extensibility and loosely-coupled components.

Simply said, the dependency inversion principle states that we need to rely on abstractions rather than concrete implementations.

What is system coupling?

System coupling is defined as the constraining state of one item to another item inside a system. Coupling occurs on context information. For example, in an air-conditioner, the compressor is said to be coupled to the internal cooling refrigerant and cooling mechanism, since these components together make up the entirety of the cooling system.

Tightly-coupled vs. loosely-coupled components?

Coupling can be of two types: tight coupling and loose coupling. These refer to how a system would react in presence of a substitute of a certain component/module.

In our example before, if the cooling mechanism of the air condition was "tightly-coupled" to the compressor, then substitution of the compressor made by other companies are highly likely to break the cooling mechanism entirely. This would be an example of a tightly-coupled component system. Tightly-coupled components have concrete, hard-coded implementations.

Loose coupling is the exact opposite of the example above, where replacement of a system with one of a similar function but of different constitution/implementation, will ensure that the system works as these.

Let's look at a code example now

Following with our analogy from before, we define a simple AirConditioner class:

class CompressorV1 {
  constructor() {
    console.log("Compressor V1");
  }

  setup() {
    // perform some necessary setup task
  }

  turnOn() {
    this.setup();
    // function code
  }
}

class AirConditioner {
  private compressor: Compressor = new CompressorV1();

  constructor() {}

  public powerOn() {
    this.compressor.turnOn();
  }
}

The CompressorV1 object is a direct dependency in this AirConditioner class. If a new modification was to be made according to our analogy, this would break the AirConditioner class as it doesn't have a way to extend functionality to operate with a new Compressor type. Without implementing the dependency inversion principle, this would be the future snapshot of the code, if a new compressor CompressorV2 was introduced to the air conditioner:

class CompressorV2 {
  constructor() {
    console.log("Compressor V2");
  }

  setup() {
    // perform some necessary setup task
  }

  turnOn() {
    this.setup();
    // function code
  }
}

class AirConditioner {
  private compressor: Compressor = new CompressorV1();
  private compressor2: CompressorV2 = new CompressorV2();

  constructor(private activeCompressor = 1) {}

  public powerOn() {
    if (activeCompressor == 1) {
      this.compressor.turnOn();
    } else {
      this.compressor2.turnOn();
    }
  }
}

The problem suddenly becomes evident.

The code won't scale well upon addition of a multitude of different components that are core dependencies in the AirConditioner class and may need to be replaced in the future. And even if the components don't need replacement, using if-else blocks in this way is not good for production code. It is a known fact that the more the decision branches are encountered during code execution, the slower the execution will be.

Inversion of control (IoC)

From the above example, we see that the AirConditioner class is in charge of instantiating and managing the compressor objects. This results in a tedious type of code pattern, where everytime a new Compressor was introduced, someone would have to modify the AirConditioner class to support the new Compressor type.

However, let's look from a different angle. Instead of letting the AirConditioner class handle the lifecycle of the compressor objects, we define an abstract compressor interface that handles it for the AirConditioner. We'll name this interface ICompressor (adding an I in front is just a naming convention for interfaces).

Why an interface, you ask? An interface allows us to define a particular type of function, without actually implementing it. Thus, we define an interface of a compressor that has the declaration of "setup" and "turnOn" but not the definition of it.

interface ICompressor {
  setup(config?: any): any;
  turnOn(): any;
}

Each compressor class would now implement this interface. The resulting code:

class CompressorV1 implements ICompressor {
  constructor() {
    console.log("CompressorV1 is in system");
  }

  setup(config?: any): any {
    // perform the very same setup tasks in this interface function
  }

  turnOn(): void {
    // same function code
  }
}

class CompressorV2 implements ICompressor {
  constructor() {
    console.log("Compressor V2 is in system");
  }

  setup(config?: any): any {
    // perform the same necessary setup task
  }

  turnOn(): void {
    // same function code as before
  }
}

Moreover, the AirConditioner class looks much cleaner with this elegant interface design:

class AirConditioner {
  constructor(private compressor: ICompressor) {}

  public powerOn() {
    this.compressor.turnOn();
  }
}

If we were to run our program now, this is how it'd look:

class Main {
  static main(args: string[]): Number {
    const ac: AirConditioner = new AirConditioner(new CompressorV1());
    ac.powerOn();
  }
}

What we did just now is known as Inversion of Control. This process removes the dependency of the AirConditioner on the Compressor classes. So to generalize, we have inverted the dependency control flow where the higher level module (AirConditioner class) was depending on the lower level module (CompressorV1 / CompressorV2 classes) by introducing an even higher level abstraction (ICompressor).

One more example

Now in our above air conditioner case, it is not uncommon that a complex behavior may be introduced. Suppose, a third type of compressor came along and we need to provide support for this type of compressor in our ACs as well. But the setup process for this compressor is a bit different. Unlike the first two types that had completely offline setup processes, this one has a remote connection module that is needed to be configured for the compressor system resource monitoring before the compressor can be turned on.

The third compressor therefore has a different internal setup behavior as it relies on an asynchronous request to finish before its setup task can be completed.

Thanks to the implementation that now uses a higher level abstration, this new type of compressor can be very easily integrated in our air conditioners. We simply implement one more Compressor class in the following way, but this time the turnOn function is implemented as an async function. This is a completely valid modification as interfaces only ever care about the signature of the function and never about how the function is implemented.

class SmartCompressor implements ICompressor {
  constructor() {
    console.log("Smart Compressor is in system");
  }

  loadConfiguration(): any {
    //function to load connection configuration
  }

  setup(config?: any): Promise<any> {
    // perform the same necessary setup task
  }

  async turnOn(): void {
    const configObject = loadConfiguration();
    try {
      await this.setup(configObject);
      // function code to turn on compressor
    } catch (err) {
      // catch error if connection fails
      console.log(err.message);
    }
  }
}

Even though the process of setting up the compressor is very different this time, dependency inversion ensures this new addition will not need a complete re-iteration of our system (notice how we don't even have to touch our AirConditioner class this time), thus saving us time and the loss of sanity. This system has now been converted to a loosely-coupled system with the help of the dependency inversion principle.

Conclusion

In summary, this is what the Dependency Inversion Principle states and intends to implement. It is clearly visible how and why loosely coupled architectures favor this principle to be staged in place and also why it made the list on the S.O.L.I.D software design principles.

Build a highly available Node.js application using Docker, NGINX and AWS ELB

Sowmen Rahman — Thu, 15 Apr 2021 09:40:57 +0000

What is load balancing?

Load balancing is a technique(algorithm) used to distribute incoming network traffic onto a group of servers. It provides a single entry point for all public users to a service hosted by a server. Production-grade servers are generally run behind load balancers because they can “even-out” the incoming load across the servers, thus preventing server overloads. Load balancers also provide a secondary functionality to the servers they are routing traffic to: they act as a reverse proxy. A reverse proxy is like a middle-man between the group of servers and the users. All requests handled by the reverse-proxy are forwarded to the appropriate server based on the request conditions. The server then responds back with its data, which is then directed to the users from the reverse proxy. In this way, r-proxies keep the identity of servers anonymous alongside preventing access to the main servers where sensitive data like configuration files, tokens, secrets, etc. are stored.

NGINX and AWS ELB as load balancers

NGINX is a fast and free open-source load balancer that can also act as a reverse proxy. On the other hand, ELB is a load-balancing service provide by Amazon AWS. ELB can further be of 3 main types: (1) ALB, (2) CLB and (3) NLB. A newer class of load-balancers called the gateway load-balancers have also been add into the family of cloud services AWS provides. The idea for this tutorial is to form a cascading multi load-balancer architecture that can provide a highly available Node.js server running on multiple ports.

Note to users : There are many ways of implementing infrastructure for Node.js applications on AWS, including ones that utilize AWS’s own ECS and ECR ecosystem for docker applications. However, this tutorial doesn’t focus on that, and aims to better understand the mechanism behind EC2 instances, load balancers and how they interact with docker over load-balanced and proxied ports.

Overview of the architecture

This is the architecture that we’re aiming for. Multi-level load balancers managed by AWS and NGINX which will help us maintain multiple ports on each EC2 instance for our node apps. The good thing about this architecture is that the 2 instances are in different availability zones (AZ1 and AZ2), as a result, even if one zone goes down, the other zone remains functional. And our application doesn’t crash.

The Node.js app

For the sake of simplicity, we use a standard starter Express node app, which looks like this:

The ports are provided to the express app via the PORT environment variable. We will feed these port values via Docker. This is a very simple task thanks to docker-compose. There’s another environment variable SERVER_ID, however don’t worry, as it’s only for demonstration purposes only. Once the whole setup is ready, the SERVER_ID will let us know which server the load balancers are pulling the response from. This will help us to validate that our infrastructure configuration using the multi-level load-balancer/r-proxy is running the way it should be.

These type of configurations are common in production pipelines. Generally the main app servers are placed in a VPC in such cases. One informational point about the load balancers is that, level 1 load balancers are often categorized as public-facing, as they deal with the actual client requests, while those at level 2 are internal load-balancers, whose job is to route requests between sources.

Launching EC2 servers

Log in to your AWS account and go to EC2 dashboard. We will be following these steps to setup new servers and get them ready for Docker:

From the dashboard, click on Launch instances at the top-right corner.
From the quick start section, select Amazon Linux 2 AMI.
Choose instance type t2.micro (you can avail the free tier on this instance type if its still available on your account). You may also choose any other type you like instead.
For this demonstration only, we’ll launch the 2 instances separately, since we want these two instances in different availability zones. In my case, the region is us-east-1, so I selected the default subnet under us-east-1a.
Under User data section, paste code from this script below. This will install the prerequisite software for running our node.js docker apps.
For Add Storage and Add Tags sections, keep the defaults and skip.
For Configure Security Group, create a new security group with ports 22(SSH) and 80(HTTP) open. For IP range you may select Anywhere or My IP*8. Since this is for testing only, you may choose either one. I went with **Anywhere.
Click Review and Launch and then Launch.
Create a new keypair to SSH into this instances. We will need this later to build the docker images for the app and the internal load balancer.

The first of the 2 instances have been launched now. Follow the same steps for launching the next instance, only changing the subnet to some other value than the previous one, and using the SSH keypair you created a while ago.

Containerizing the app and NGINX configuration

For this tutorial, we will use this repo for the app:



Link: https://github.com/sowmenappd/load_balanced_nodejs_app

This will help us speed the process through. The hierarchical view of the repo is given below:

The app folder contains the node server source code along with the Dockerfile. In the nginx folder, there is a configuration file nginx.conf that defines the upstream server port configuration:



http{    
    upstream lb {        
        server 172.17.0.1:1000 weight=1;        
        server 172.17.0.1:2000 weight=1;        
        server 172.17.0.1:3000 weight=1;    
    }     
    server {        
        listen 80;        
        location / {            
            proxy_pass http://lb;        
        }    
    }
}

e configuration files specifies that the main NGINX server should listen to port 80, the root location “/” will relay the request(proxy pass) to an upstream defined in this file named lb. This is an upstream object that specifies how many servers will be included(these are the express servers that we mount via docker-compose, more on that in a later section), and what ports these servers will be internally running on, while the reverse proxy load balances the traffic from port 80.
In our case, the upstream proxy will direct traffic to ports 1000, 2000, and 3000. These port numbers must match the internal PORT value that is sent to each express server instance as an env-var, which we will define in the docker-compose YAML file.
For each of the launched instances, we do the following:

SSH into the instance using created keypair
Run the following terminal commands to build the app image from its Dockerfile



git clone https://github.com/sowmenappd/load_balanced_nodejs_app.git
cd load_balanced_nodejs_app/app
docker build -t app .

Next build the nginx server docker image



cd ../nginx
docker build -t nginx-s .

Run docker images and you should see something like this:

For the second server, we need to change the docker-compose.yml file. The env-var SERVER_ID should be changed to 2 for all apps (app1, app2, app3). This is definitely nothing to be concerned about, and no production server will ever have something like that. We’re doing this only for the sake of demonstration.
Run the final commands:



cd ..
docker-compose up -d

Your isolated servers should now be running three process of the express app in the background. All we need now is to mount this system using the load-balancer AWS gives us, AWS ALB.

Mounting the system with AWS ALB

At this point, both the instances are ready for mounting. We are going to set up an application load balancer in AWS by following these steps:

Navigate to EC2 Dashboard and click on Target Groups. Click Create target group.
Choose target type: Instances and provide a valid target group name, and click Next.
Select the two running instances and click Include as pending below, with the port as 80.
Click Create target group.
Next, click on Load balancer from the side menu (left).
Click Create load balancer and click Create on Application Load Balancer card.
In the next screen, select the availability zones you had chosen earlier while launching the instances, and proceed.
Create a new security group with port 80 open to all IP range, and then click Next.
Select Existing target group, and point it to the target group you created.
Rest of the settings are fine, you can click on Create.

The load balancer should be up and running within minutes after registering the instances and getting health checks running. Now, we grab the DNS name of the load balancer from EC2 Dashboard > Load balancers, copy the DNS name attribute of the load balancer.

Paste the DNS name into the browser, and hit Enter. You will see that every time you refresh your browser page, the response sends back different PORT and SERVER_ID values. This validates the system because by default, NGINX and AWS load balancers use Round Robin algorithm for load balancing.

Conclusion

Our system is now guaranteed to be very highly available and able to withstand spiky and massive amount of traffic over prolonged durations of operation, given the multi-load balancer configuration we have deployed. As a follow up to this tutorial, I shall also post another article showing how to create and maintain a deployment pipeline that integrates with source control and deploys our changes to the servers upon commits to the GitHub repo.

Resources

Blue/Green deployment strategy

Sowmen Rahman — Wed, 10 Feb 2021 07:39:51 +0000

What is blue-green deployment?

The strategy gets its name from the idea of having two concurrent environments, and switching between environments. The environments have different code revision signatures.

The blue environment is the old environment.
The green environment is the newer and more updated environment.

Since the deployment process changes the web pointers from the blue environment to the green environment, it is known as the Blue-Green deployment strategy.

Of the many benefits provided by the blue-green deployment strategy, the most important few are:

1. Software & service downtime reduction

If production deployments relied on a single environment, there would definitely be server downtime, owing to the time cost of source code updates and patches. However, if there are two environments running concurrently, this downtime gets reduced to nil given there occurs no mid-modification issues.

2. Experimental feature testing

When new features need to tested publicly, this strategy offers significant advantages. Since the idea of this strategy involves having 2 environments, a small portion of the users can be exposed to one of the environments with the experimental features. Depending on the response of the users, devs can take further decisions about the impact of the new features, change the ratio of exposure or totally upgrade to the new version.

3. Isolation for testing and production environments

One of the better uses of blue-green deployment strategy is keeping the development and production environments separated from each other. Devs should never have to worry about writing new code or changing infrastructure which will directly impact the live servers. This will only cause public frustration..

..something which can easily turn into memes

4. Crashes and rollbacks

One of the more common and mostly frightening term for any software company on earth would be crash. But even though, code has been tested hundred of times before release, there might be times when a few bugs may jump out of the bucket. Critical ones. Having a blue-green deployment technique can be a life-saver during these cases, as teams can switch back to the stable older environment where those bugs are not encountered, thus giving them freedom and salvation from the torment of the public and media as they sit down to fix the bugs and redeploy again. If some different deployment technique (in-place deployment) was used instead, rollbacks would become very lengthy as there would be no older environment to switch back to.

In the industry of cloud and web tech, blue-green or canary deployment are still one of the main and most popular deployment strategies that is used to upgrade running servers with the latest production code. Every big software company (Facebook, Google, Amazon, and so on..) has used or is still using this strategy for their deployments because of the conveniences it provides.

However, a downside to this strategy is that, as the switching of the environments are handled by the load-balancers, a switching time-delay due to DNS propagation occurs. DNS servers are updated with the correct server DNS names(their unique address on the web) via propagation, which means, it takes time to reach every domain name server across the planet. As a result, people of some regions of the world may not be able to access the changes in the servers as soon as the deployment happens, because the DNS servers closest to them are still pointing to the older servers. Sometimes, when a new deployment has taken place with bugs in the code, a rollback although issued instantly will not be perceived in every part of the world. So people will still be looking at the buggy version of the software even though the buggy version has been correctly roll backed from.

Although these can occur, proper trial and testing can help resolve these problems before they are released to the open world. Compared to the bigger pool of advantages, these problems are easily overlooked and are the reason why blue-green deployment strategies are still preferred today.

An introduction to the theory of DevOps — why, when and how?

Sowmen Rahman — Mon, 25 Jan 2021 18:26:39 +0000

So.. what’s this buzz about DevOps? It won’t kill you to know about how DevOps may save your time and sanity writing code.

Let’s look at a dev scenario.

It wasn’t that long ago, when coders used to write company software code, build it, then hand over the new version to the operations team for testing and debugging. The operations team would sometimes also do this ‘quality and assurance’ testing to find out how well the software would work (with or without bugs), and the potential impact of the software’s new version on the people.

This process is a very lengthy process. First of all, there are two separate teams that are working on the same product, but stay completely isolated from each other; no communication between them other than in the contact periods of code finishes and dev responses, (and occasionally, probably at coffee breaks..)

The developer team might not be able to use feedback properly during the interim development phase from the system operations and management team (which could have accelerated the product backlog that’s been on the agile board for what, a few weeks now?)

Now, let’s look at a different scenario.

Have you ever found yourself applying for a job (presumably a small or medium startup/firm), reading the technical skill requirements on the job post on LinkedIn, and after you get hired, and take on your first major project at the company, build a few modules, connect the backend your teammates made to the frontend you coded, and then… the project manager dumps a load of irrelevant project operations tasks that don’t seem important, at the same time have you questioning why you’re the one being assigned to this? What is my role in this company? Am I a developer or am I the sysops guy? Do I really need to code anymore or is handling the platform now my main job?

If you read through that painfully long paragraph, my friend, you’re not the first one to feel that way.

Having reached that stage, you might suddenly realize that maybe you lack a vast range of skills that were never asked for the job at the first place. You may have a lot of questions. But I assure you:

As SEPTA’s slogan goes, so goes the cycle of software development at every software company that has ever existed. In context of the first scenario, when there’s simply too freaking much work for a seriously short deadline on the agile board, and for the second scenario, when there’s a wall of confusion in the mind of the developer regarding what stages of the product he’s supposed to be working on, DevOps is your friend.
Leading infrastructure and IT innovation enterprise AWS terms DevOps as

The combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.

Or as I like to say:

DevOps is a modern way to streamline activities in a software’s development phases in production.

But does this solve the problems that we have in mind?

Absolutely!

You, as part of a development team will often be under enormous pressure, thanks largely to the principles of agile development. The intense focus on constantly releasing products and their subsequent newer versions to market means that you as a team member will have a limited understanding of enterprise operations and a limited concept of risk, causing you to act like a SysOps guy haphazardly and throwing yourself plus the team, into a never-ending release cycle. The concepts of validation, long-term strategy, and the business vision start to escape your grip. This results in teams like yours in the company to become so desperately focused on the day-to-day that even major technological shifts can pass them by.

Imagine how difficult this can become if you’re working in a small team, and you’re in charge of everything that needs to happen.

Meanwhile, the operations teams in your company(in the first scenario) begin to act like development teams. They begin suggesting changes to the enterprise architecture and the production process based on issues they observe on a routine basis. Quick fixes are often applied based on a limited range of input, only to have a rollback or hotfix take place the next day. And then everything goes haywire when the solution that was implemented earlier is revealed to be the wrong one.

The process repeats itself and generally gets worse over time and ultimately the project is ready for blast-off, destination Screwed.

Stay careful when I say this as it applies easily to just about every business or company nowadays, whether you’re a business selling groceries or selling ads, small or large, all businesses are now dependent on IT in one way or the other. These problems are ever so common, and without a proper strategy, nobody will actual understand what’s going on or how to solve it. This gives rise to the mentality that company work often gets stressful trying to debug bugs and crashes. Now you know why this mentality catches on.

So how does DevOps help you in light of the problems above, I hear you ask?

Earlier on, I stated that all these massive problems that occur very frequently at tech companies at scale or not, can be solved using DevOps. Yes, now we move to the core of this story.

DevOps is the result of many years of software development practices, all refined to form a culture that aims to refine the cycle of software development itself.

Cool, isn’t it?

DevOps is not a tool, but a cultural practice that intends to solve complex problems while building a software that requires developing, building, testing and deploying. Along with Q&A, these 4 are the core phases in the development cycles that all software releases go through. And the problem occurs when there are different teams that miscommunicate how different problems are tackled during any of the phases, like the ones we saw above.

The idea of DevOps is to automate various processes in this massive cycle by breaking it up into smaller tasks, so that these do not have any complex dependency. So whenever a problem looms up in the testing phase, that problem doesn’t bog up the coding or building cycle for that matter.

The industry of software has been undergoing rapid changes regarding it’s development strategies. One of the software development strategies that we have seen above, also one of the most common strategies seen in many companies during developing production-grade software, works by separating the development and operations team. This separation can cause countless problems(as described earlier).

DevOps at it’s core, aims to manage these problems by uniting the different teams on the project. These teams are no longer “siloed” to their technical and/or operation roles. The teams start to work together and the activities of the entire application development cycle is distributed to all role-players in the company. One of the perks of doing this is that, the engineers no longer focus on only the code, but also the underlying architecture which helps them to identify and prevent problems at an early stage. The operations team on the other hand gets to interact with the code, and therefore by analyzing how the components in the app/product work can make infrastructure optimizations.

To take on the advantages of DevOps, a change of mindset is necessary. A shakedown of the “no-dependency strategy” of dev and ops need to happen, for better efficiency thus, unite the teams.

DevOps requires a set of tools(software) or a technology stack, that helps with the management of code and infrastructure, deployment of code and server configurations. No matter how the teams decide to choose, a useful set of tools is crucial for a good DevOps environment. Engineers can then automate processes by running small tasks, change the system specs when the software itself starts to evolve, evidently it helps the company push out product faster to the growing customer pool. These eventually become a habitual practice at the company, allowing developers and system admins to grow from their separate roles to learning a range of functions that also help them in various tasks. This increases the team’s velocity in a development cycle. A strong leadership and willingness to take responsibility of one’s own action and role in the cycle is also a key ingredient for the success of this environment. By adopting DevOps, the devs and ops teams not only work better together but progress to a unity point in the company where confusion about the product and development cycle is minimized.

DEV Community: Sowmen Rahman

When should you cache your APIs?

What is caching?

Client-side caching

Server-side caching

Cache Hit Ratio

When should you cache your APIs?

Read-intensive data endpoints

Cache expiry manipulation

Cache as a request idempotence guarantor

Database caching

Reducing metered third-party API calls

Distributed applications

Cache key generation

Cache servers as rate limiters

Conclusion

I built an open source app where you make friends by helping them

THE IDEA

WHY THIS IDEA?

TECHNOLOGIES

HRN STACK?

PROJECT FEATURES

Authentication

Login page

Signup page

Post sharing

Searching

Messaging

User view for public posts

Before a user messages a person for help response

After a user messages a person who needs help

Notifications

Mobile-friendly and responsive layout

PROJECT ROADMAP

CONTRIBUTION

CHALLENGES

LINKS

Understanding SOLID: Dependency Inversion Principle

What is the dependency inversion principle?

What is system coupling?

Tightly-coupled vs. loosely-coupled components?

Let's look at a code example now

Inversion of control (IoC)

One more example

Conclusion

Build a highly available Node.js application using Docker, NGINX and AWS ELB

What is load balancing?

NGINX and AWS ELB as load balancers

Overview of the architecture

The Node.js app

Launching EC2 servers

Containerizing the app and NGINX configuration

Mounting the system with AWS ALB

Conclusion

Resources

Blue/Green deployment strategy

What is blue-green deployment?

1. Software & service downtime reduction

2. Experimental feature testing

3. Isolation for testing and production environments

4. Crashes and rollbacks

An introduction to the theory of DevOps — why, when and how?

So.. what’s this buzz about DevOps? It won’t kill you to know about how DevOps may save your time and sanity writing code.

Let’s look at a dev scenario.

Now, let’s look at a different scenario.

DevOps is a modern way to streamline activities in a software’s development phases in production.

Absolutely!

Imagine how difficult this can become if you’re working in a small team, and you’re in charge of everything that needs to happen.

The process repeats itself and generally gets worse over time and ultimately the project is ready for blast-off, destination Screwed.

So how does DevOps help you in light of the problems above, I hear you ask?