DEV Community: Raymond Ottun

Continuous Deployment Patterns

Raymond Ottun — Fri, 19 Jan 2024 08:01:18 +0000

In this post, I will discuss different deployment patterns that you can use to deploy your application into production. The point of these deployment patterns is reduce downtime and provide easy rollbacks incase of a defective deployment.

The effect of these patterns can be observed using application telemetry data.

Recreate Deployment

With this deployment pattern, you deploy a new version of your application and delete the existing version of the application. This is the simplest deployment pattern, but it can result in downtime for your application as shown in the following diagram.

Ramped

With this deployment pattern, you deploy a new version of your application alongside the existing version of the application. Once the new version is ready, you gradually shift traffic from the existing version to the new version. This is the default deployment strategy in Kubernetes.

Canary

With this deployment pattern, you deploy a new (canary) version of your application alongside the existing version of the application in production. Once the new version is ready, you shift a small percentage of traffic from the existing version to the new version and keep monitoring the canary version. If the canary version performs well, you continuosly
shift traffic to it until all production traffic is now served by the canary version. If during the traffic shifting, the canary version performs poorly, you stop shifting traffic to it and continue to use the existing version.

Blue/Green

With this deployment pattern, you deploy a new version (green version) of your application alongside the existing version (blue version) of the application in production. Once the new version is ready to accept traffic, you switch 100% of the production traffic from the existing (blue) version to the new (green) version and then shut down the old version.

A/B Deployment

With this deployment pattern, you can test a new version of your application by deploying it to a subset of users alongside the existing version of the application.

Usually, traffic is sliced between the versions using request headers/cookies. The load balancer can then direct traffic to different versions of the applications using these request values

Shadow

With this deployment pattern, you can test a new version of your application by deploying it alongside the existing version of the application. However, instead of sending client traffic to the new version, you send a copy of the traffic to the new version. This allows you to test the new version without impacting the existing version.

Hopefully, this post has given you a better understanding of different deployment patterns that you can use to deploy your application.

If I missed any deployment pattern, please do let me know in the comments below.

Microservices, The bad parts

Raymond Ottun — Mon, 15 Jan 2024 18:06:12 +0000

If your team is considering microservices, you should be aware of the challenges associated with them.

Microservices are a great way to scale your application, but they come with a lot of overhead. In this article, I will talk about the challenges and considerations associated with microservices.

Local Development

Developing and testing a monolith is straightforward as developers can run the entire application on their workstation. However, with a microservices architecture, developers need to run each service individually or together depending on the coupling between the services. This setup increases the complexity of the development environment and can lead to frustration and reduced productivity if not managed properly.

Testing

Testing a microservices architecture, especially end-to-end or integration testing, requires a more complex setup compared to a monolith. Services may need to be mocked or spun up before tests can be executed. The testing framework needs to account for this complexity, such as waiting for services to be up and running before starting the tests.

Debugging & Tracing

Tracing requests through multiple services in a microservices architecture requires careful consideration. Without proper tracing in place, debugging issues in production can be challenging. For example, if a client request is handled by service A, which then calls service B, and then service B calls service C, it can be difficult to debug an issue in service C without proper tracing.

External Services Dependency

Managing dependencies among services can be challenging, especially when different teams are responsible for different services. Services may need to be mocked during testing or development. Additionally, deploying microservices requires deploying each service individually, which can be time-consuming and complex to set up and debug.

Versioning & Dependency

Proper API versioning is crucial for managing dependencies between services. If service A depends on service B, any changes in service B may require updating and deploying service A. Deciding which service to deploy first can be tricky. If service A is deployed first, service B may be broken until service B is deployed. If service B is deployed first, service A may be broken until service A is deployed. Services should strive to be backwards compatible if versioning is not in place.

Deployment

Coordinating service deployments and managing multiple services require careful planning. Deployment pipelines need to be designed to handle multiple services efficiently and minimize duplication.

Conclusion

While microservices offer scalability benefits, they also come with significant challenges. Designing the architecture with careful consideration can help mitigate the pitfalls mentioned above.

This article is not meant to discourage you from using microservices. Instead, it is meant to help you understand the challenges associated with microservices so that you can make an informed decision about whether or not they are right for your team.

isNaN is like gambling

Raymond Ottun — Fri, 12 Jan 2024 08:07:39 +0000

isNaN is a nice function that checks if a value is not a number but has been the source of many sleepless nights and wasted weekends for developers. The reason for this is that isNaN is not a reliable way to check if a value is not a number. Let me show you some examples:

Example 1

This is the expected behavior of isNaN. It returns true if the value is not a number and false if it is a number. In this case, 'hello' is not a number so isNaN returns true. So far so good.

isNaN('hello') // true

Example 2

This is where things start to get weird. The value is not a number but isNaN returns false.

isNaN('123') // false

This is because isNaN converts the value to a number before checking if it is not a number. In this case, '123' is converted to 123 which is a number so isNaN returns false. So if you want to check if a value is not a number, you can use the following function:

Example 3

How about null? It is not a number so isNaN should return true right? Wrong. It returns false.

isNaN(null) // false

null is converted to 0 before checking if it is not a number. Since 0 is a number, isNaN returns false.

Example 4

What if your value happens to be undefined?

isNaN(undefined) // true

This is because undefined is converted to NaN before checking if it is not a number. Since NaN is not a number, isNaN returns true. In this case, isNaN works as expected.

Example 5

What if your value happens to be true or false which are not numbers or so you thought?

isNaN(true) // false
isNaN(false) // false

isNaN will "helpfully" convert true to 1 and false to 0 before checking if they are not numbers. Since 1 and 0 are numbers, isNaN returns false.

Example 6

Have you ever mistakenly passed in "" or " " to isNaN? You are in for a surprise.

isNaN("") // false
isNaN(" ") // false

The "brilliant" isNaN function will convert "" and " " to 0 before checking if they are not numbers. Since 0 is a number, isNaN returns false.

Example 7:

So for whatever reason, you find yourself checking if a Date object is not a number. What do you think will happen?

isNaN(new Date()) // false

That's right. isNaN will convert the Date object to a number before checking if it is not a number. Since the Date object is converted to the number of milliseconds since January 1, 1970, 00:00:00 UTC, it is definitely a number so isNaN returns false.

Example 8

[] and {} behave differently when passed to isNaN further adding to the confusion.

isNaN({}) // true
isNaN([]) // false

{} is converted to NaN before checking if it is not a number. Since NaN is not a number, isNaN returns true. On the other hand, [] is converted to 0 before checking if it is not a number. Since 0 is a number, isNaN returns false.

Conclusion:

If you want to save yourself from a lot of headaches, you should know that isNaN is a very unreliable way to check if a value is not a number. If you want to check if a value is not a number, you can use the following function:

function isNotANumber(value) {
  return typeof value === 'number' && isNaN(value);
}

This function checks if the value is a number and if it is, it checks if it is NaN. If it is NaN, it returns true. Otherwise, it returns false.

isNotANumber('hello') // true
isNotANumber('123') // true
isNotANumber(null) // true
isNotANumber(undefined) // true
isNotANumber(true) // true
isNotANumber(false) // true
isNotANumber("") // true
isNotANumber(" ") // true
isNotANumber(new Date()) // true
isNotANumber({}) // true
isNotANumber([]) // true

Preparing for the Role of a (Senior) Full Stack Developer

Raymond Ottun — Mon, 08 Jan 2024 18:40:52 +0000

As we embark on a new year, if you are considering a career change or aspiring to step into the realm of a (Senior) Full Stack Developer, it's essential to prepare thoroughly for potential interviews.

This article aims to guide you on the key topics you should be well-versed in to confidently tackle Full Stack Developer interviews.

HTML, CSS, JavaScript

Mastering the fundamentals of web development is crucial. As a Full Stack Developer, ensure your proficiency in:

Accessibility
SEO
Forms
Web APIs (e.g. localStorage, fetch, history)
CSS Layout (e.g. Flexbox, Grid)
JavaScript Fundamentals (e.g. this, prototype, async, await, Promise)

Example HTML, CSS, JavaScript Questions

What is the difference between null and undefined?
What is event bubbling?

Web Frameworks

Familiarity with at least one web framework is expected. Notable frameworks include React, Vue, and Angular. Focus on the following areas:

Components
State Management
Routing
Server Side Rendering

Example React Question

Why use useReducer instead of useState?
What is prop drilling and how can it be avoided?

Server Programming Language (e.g. Node.js or Python)

Full stack developers should excel in at least one server programming language, typically Node.js. Key areas of expertise include:

Express (or other web frameworks)
REST APIs
Node.JS event loop
Async programming (e.g. callbacks, promises, async/await)
Streams
WebSockets
REST APIs
GraphQL

Example Node.js Questions

Why is the following code not a good practice in error handling?


process.on('uncaughtException', (err) => {
  console.log('Caught exception: ' + err);
});

What is the difference between process.nextTick and setImmediate?

Web Security

Understanding common web security vulnerabilities is crucial. Equip yourself with knowledge in:

CORS
CSRF
XSS
SQL Injection
HTTPS
Content Security Policy
Authentication (e.g. JWT, OAuth)

Example Web Security Questions

What is the purpose of a CSRF token?
What is the purpose of a CORS policy?
What is the purpose of a Content Security Policy?

DevOps

Efficient deployment and maintenance are integral skills. Focus on the following:

Docker
CI/CD
AWS (or other cloud providers like Azure or GCP)
Observability (e.g. logging, monitoring, tracing)
Infrastructure as Code (e.g. Terraform)

Example DevOps Questions

What is the relationship between Docker and Kubernetes?
Why is application observability important?
What are the common stages in a CI/CD pipeline?

General Engineering Practices

Adopting standard engineering practices is key. Ensure familiarity with:

Testing (e.g. unit testing, integration testing, end-to-end testing)
Git (e.g. branching, merging, rebasing, squashing)
Agile (e.g. Scrum, Kanban)
Refactoring
Code Review

Example General Engineering Questions

What is the difference between unit testing and integration testing?
What is the difference between rebasing and merging?

Databases

Database knowledge is foundational. Key areas of understanding include:

SQL (e.g. joins, aggregations, indexes)
NoSQL (e.g. key-value stores, document stores, graph databases)
ACID
Transactions
Database Indexing

Example Database Questions

What is the purpose of a database index?
What is the difference between a primary key and a foreign key?

Remember, this list is a starting point. Tailor your preparation to align with the specific needs of the company you are applying to.

It's natural to feel overwhelmed, but focus on continuous learning. You can acquire these skills gradually and even on the job. Be curious and open to learning.

To aid your revision for a Full Stack Developer role, consider using the list of questions I've compiled in this repo in the form a quiz with a small web app to practice Github Revis3, categorized by topics:

I hope you find this useful. If you have any feedback, please let me know.