Recep Inanc | Software Engineer

How to Read Technical Books Effectively

2022-02-19T00:00:00+00:00

My way of reading technical books effectively.

Photo by Sincerely Media on Unsplash

Reading a technical book is a lot different than reading a novel. That is why we need a different strategy to get the best out of technical books. I have been in the pursuit of a good reading technique for years now. I have tried to follow different approaches and finally, I was able to find a way that works for me well. In this post I will share my way of reading technical books in the most effective way.

What do I mean by “Effective”?

Actually, the use of the word “effective” here, depends on the type of the book. If the book is a “Reference” book, “effective” means after reading the book, I know where to look for answers. If it is not a reference book, “effective” means after reading the book, I learned the knowledge shared in the book.

I think of Reference books as they are set of tools that I add up to my toolkit, and use whenever I need. I don’t have to carry all the tools I have with me, I will just “refer” to them when I need them. On the other hand, I consider non-reference books as techniques that I actually learn. I do not have to spend extra effort to use them, I already have them with me all the time.

Some of my favorite reference books:

Some of my favorite non-reference books:

Photo by Aaron Burden on Unsplash

The Strategy

Reading a technical book in one sitting might be overwhelming. Especially when you have no idea what is coming next as you read. When you don’t know how deep the rabbit hole will go, it makes you feel lost as you read and dive deeper into the concepts. The below strategy I developed over years is to overcome this struggle.

Does not matter if you follow the upcoming step-by-step guide or not, it is crucial to keep in mind the following:

Understand the terminology. If you encounter a term more than once, you need to make sure that you understand what it means. The more you encounter, the higher the chances of that term being important.
Know when to stop. I have always thought to understand something I need to go as deep as possible on that topic. But that is not always very efficient. Sometimes you have to draw the line to stop dwelling on the theory and get into practicing (if applicable).
Review your notes. Note taking is an important habit when it comes to reading a technical material - be it books or documents. And to make the most out of your notes you need to review them on a regular basis. This will help you internalize what you have learned from that book. And over time you will realize the need to review lessens.

These are in mind, let’s get to my way of step-by-step reading a technical book efficiently.

0. Read the Preface/Foreword

Author’s of technical books usually include a very important part in these sections. They share “What is this book about?”, “Who should read it?”, “What each chapter explains?”, and sometimes even “How to Read?”. I find this information very useful before starting to read the book. Who could know the best way to read the book better than the author, right?

1. Scanning

I scan the chapter I am going to read. Scanning should be fast, and it should not take much of my time.

I go over the titles,
I glance over the images,
I observe how long the chapter is and decide if I need to split it into smaller chunks.

2. Skimming

Skimming is again faster than the actual reading but slower than scanning.

I pay more attention on the subtitles, captioning of the images.
I read the first and last sentences of each paragraph.
I read the code snippets.
I try to get the main idea of each part and do not spend time on details.
I try to take mental notes of what might need more attention and what might not during the full reading phase. Please note that I use the term “mental” here because I do not want to spend time taking physical notes. It is way easier to remember “Yeah, this looks important” in your head than typing/writing “Pay attention to X”.
I do not linger. This is something I found important because it is easy to get started reading the whole thing as you try to skim.

3. Complete Reading

This is when the previous steps pay off.

I read the chapter completely.
I pay attention to the parts I took a mental note of during skimming.
I close the book and take notes in my own words. For me, it is usually hard than it sounds. But it is essential to use your own words. To describe what you’ve read you need to find the correct words, what do those words mean to you. And since you are taking notes you need to be able to summarize it. Sometimes as I write my notes I realize that I cannot find a word to describe it or even better start to question what I am writing down. This is a good indicator that I have not understood that concept in enough detail to internalize.
I write down my questions. I usually keep reading and collecting my questions with the hope that they might get answered as I read. If I could not answer my questions as I read the book, they will be my next topics to research.

4. Bonus!

Here’s the best part. If you are like me and spend some extra time when taking notes trying to make them look beautiful, with a few little adjustments you can publish them as a blog post!

Conclusion

Everyone’s learning process is different, and this is mine. I wanted document it and share with you all. Who knows, someone with a similar learning process may find this post very useful! You can apply the ideas I share above to any technical material with a few little tweaks.

Basics Of Consistency And Locking In Databases

2022-02-13T00:00:00+00:00

Let’s learn about consistency, transaction isolation levels and locking in InnoDB.

ACID

A database transaction is a unit of work performed in a database management system. Such as creating a record, updating a record, deleting a record and so on.

ACID is an acronym that stands for Atomicity, Consistency, Isolation and Durability. These are the four properties of a reliable database transaction.

“C” for Consistency

This blog post focuses on the consistency aspect of database transactions.

Consistency ensures data integrity intact at all times. Meaning, the database will be in a valid state at all times.

Let’s imagine a shopping scenario to understand consistency better. The following may represent the steps to process such action:

User adds item to cart
Item quantity checked
User pays for the item using their online wallet
Payment approved
Item quantity updated
User balance updated
Order processed

Item ID	Price	Quantity
9	200.00	1

Wallet ID	Balance
42	500.00

Imagine these steps are part of a single database transaction. We expect a consistent database to be in this state once the transaction completes:

Item ID	Price	Quantity
9	200.00	0

Wallet ID	Balance
42	300.00

This shows that database was never been in an invalid state. If consistency was not guaranteed we could have the database in such state:

Item ID	Price	Quantity
9	200.00	0

Wallet ID	Balance
42	500.00

Do you see the problem here? Database processed the order but for some reason the wallet balance is not changed. This is an inconsistent state for the database. And this inconsistency may damage our business.

What happens at different level of Consistency lacks?

Three phenomena explain what might happen in case of a failed consistency guarantee.

In databases “committing” means permanently saving the data in the database.

1. Dirty Reads

Transaction T1 can read a not yet committed data from other transactions.

Imagine the transaction for the above shopping to look like this:

BEGIN;
“User adds item to cart”
“Item quantity checked”
“User pays for the item using their online wallet”
“Payment approved”
“Item quantity updated”
“User balance updated”
“Order processed”
COMMIT;

Now imagine that there’s only one item left in the stock.

User 1 starts the transaction T1 goes through the steps 1 to 8.
Right after that User 2 tries to view the details of this item.

Even though transaction T1 is not completed yet User 2 will see that the item is out of stock.

Now imagine for some reason T1 fails before committing. Now User 2 thought the item was out stock although User 1 could not buy the item.

2. Non-Repeatable Reads

Transaction T1 reads a row twice and gets different results. This might be because another transaction changed a value in the row or deleted the row.

3. Phantom Reads

Transaction 1 executes the same read statement and see rows were not shown with the first read. This might be because another transaction inserted new rows that match T1’s read criteria.

For our hypothetical example, we could avoid the issues shown above with a better design. There are also different isolation levels that brings different levels of consistency. Choosing an appropriate isolation level for our business is a critical decision.

Understanding Locks

Before moving on with transaction isolation levels, let’s understand what different locks mean.

Locking is all about achieving the promised level of consistency. To do so, each isolation level uses different locking methods based on their promise.

Shared Lock (S Lock)

The transaction that holds the lock can read the row.

If a transaction T1 holds a shared lock on row R:

-Second transaction T2 can acquire an S lock on the row R. They “share” the lock and both can read the row at the same time.

-Second transaction T2 cannot acquire an X lock on the row R. T1 does not share the lock and prevents T2 from modifying the row R.

Exclusive Lock (X Lock)

The transaction that holds the lock can update or delete the row.

If a transaction T1 holds a exclusive lock on row R:

-Second transaction T2 cannot acquire an S or an X lock on the row R. The lock belongs only to T1 until T1 releases it.

Non-Locking Reads

Non-Locking reads are the “SELECT” statements that does not put a lock on the rows. These are plain “SELECT” statements in the form of “SELECT … FROM …”. They do not guarantee consistency.

Locking Reads

Locking reads are the “SELECT” statements that puts a lock on the rows to prevent others from changing them.

Record Lock

A record lock is a lock only on the index record. This lock prevents others from modifying that record.

Gap Lock

Gap Locks are set on a gap between index records. It is to prevent other transactions from inserting new rows into the locked gap.

Gap locks are a part of the next-key lock. InnoDB uses locks the related gaps to make sure we do not encounter phantom rows in the range we are working on.

Next-Key Lock

Next-key locks are combination of record locks and gap-locks. A record lock on the record and a gap lock is set in the range we do not want to be effected by another transaction. This might be the gap before and/or after the record we are dealing with.

Transaction Isolation Levels

Transaction isolation levels are like presets with different levels of consistency-performance trade-offs.

Transaction Isolation Levels on Consistency-Performance Scale

Different transaction isolation levels solve different problems.

Read Uncommitted

At this level, transaction isolation is at the lowest - they are not isolated and no locks are set when at this level. Each transaction will read the latest change by other transactions. Even though those changes are not committed yet. This may result in dirty reads.

Read Committed

At this level, transactions only read only the committed changes by other transactions. This level only prevents dirty reads.

For “SELECT … FOR UPDATE”, “SELECT … FOR SHARE”, “UPDATE” and “DELETE” statements InnoDB locks the index records. This is to prevent other transactions from modifying those rows.

Repeatable Read

This is the default transaction isolation level for InnoDB.

At this level, the reads inside a transaction are consistent. The transaction takes a snapshot of the current state with the first read and uses that through out the transaction. This ensures that all reads can be repeated in the same transaction, thus the name Repeatable-Read. This level prevents dirty reads and non-repeatable reads.

At this level, InnoDB uses next-key locks for searches and index scans. Next-key locks prevents Phantom Reads. It is important to note that this level guarantees no phantom rows only for “Read” operations. An “UPDATE” to all the records in the table would take effect on “all the committed rows”. This includes the ones from other transactions - those are phantom rows. This means Phantom Rows can still appear at this level.

Serializable

At this level, transactions are completely isolated from each other. This prevents dirty reads, non-repeatable reads and phantom reads.

As we can see each transaction isolation levels solve different problems. The way we achieve isolation is through the use of different locking mechanisms.

Conclusion

When understanding locks in databases we need to keep in mind that the purpose is to provide a certain level of consistency. And as the saying goes, there is no such thing as a free lunch. To get more consistency we are going to need to add more locks, more locks mean more overhead, thus loss in performance. To be able to choose an appropriate solution, we must understand the needs of our system.

My Top Takeaways From Refactoring: Part 2

2022-01-29T00:00:00+00:00

Let’s talk about the principles of refactoring!

In this series, I share my top takeaways from the book Refactoring by Kent Beck and Martin Fowler. I definitely recommend reading the book to anyone interested in learning more about refactoring.

In Part 1 of this series we took a glance at refactoring in a more general sense. In Part 2, we will look at when and why to do refactoring and some more guidance on how to do refactoring.

Chapter 2 - Principles in Refactoring

In Chapter 2, Martin Fowler shares the definition of refactoring as:

“A change made to the internal structure of software to make it easier to understand and cheaper to modify without breaking its observable behavior”.

The term “observable behavior” refers to the public interface of the software. An example to that would be the public methods of a class that other classes call to interact with it. The definition makes the purpose of refactoring clear again. It is to make software easier to understand and restructure in a way that making a change is easier.

Which takes us to our first takeaway.

1. Refactoring should be Economic

I love cleaning/restructuring a piece of code! The proud feeling I get looking back at the changes is inexplicable. That’s why this was a good realization for me that we refactor for economic reasons. We should refactor not only for the beauty of the outcome but for the economic benefits we get in the long-term.

Martin Fowler mentions, we are professionals and responsible for getting the job done. And refactoring is an amazing tool that helps us achieve this goal as efficient as possible.

2. Refactoring is a Judgement Call

If we were to list those:

Improving the design of the software,
Making software easier to understand,
Finding bugs in the software,
Increasing the development speed…

Last one in the above list may sound contradictory to some people. Because they consider refactoring as “more work”. This might only be true for some cases where the actual change is so small. But it is important to remember that refactoring pays dividends in the long-term.

So it is usually a judgement call we need to make “to refactor or not to refactor”. The ability to make the right calls will develop over time as we face more of them in our career. As a starting point for making these decisions the book mentions the “The Rule of Three” by Don Roberts:

“The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor”.

3. Identify Opportunities to Refactor

How do we find the correct time to refactor? We need to learn to identify those certain occasions that suits well for refactoring.

When adding a new feature or fixing a bug. Why? It is easier to do any modification on a well-structured code base.
When trying to understand a piece of code. Why? Renaming for the better, untangling the dependencies gives us a clear picture.
When we came across a piece of code that could do what is doing better. Why? Well, because “Always leave the campground cleaner than you found it.”.
When doing code reviews. Why? It is a good opportunity to share some perspective with your colleagues. This may not be suitable for the pull-request type of code review since that process takes longer. It is more appropriate when doing pair-programming and you can discuss the suggestions.
Having a planned refactoring time. Why? In some cases - usually for the ones involving a legacy code base - refactoring may not be an easy thing to do. For such cases, planning ahead of time to pay the debt of the previous development decisions is a good call.

4. The Two Hats Metaphor / Wear Only One Hat At All Times

The book mentions a good metaphor “The Two Hats” (by Kent Beck) for the way Martin Fowler does refactoring.

It represents dividing the development time when using refactoring into two. One hat for adding a new functionality and the other for refactoring.

When we put on the first hat, we should focus on adding the new functionality (and its tests, please) only. We should not be making any changes to the existing code.
When we put on the second hat, we should focus on restructuring the existing code and keeping the tests pass. We should not add any new functionality (not even new tests).

We may keep switching the hats during the development process. But remembering which hat is currently on is essential.

Kent Beck shares this note about The Two Hats:

“Once the refactoring hat is on, note the things you think are not right about the code, but resist the temptation to change it right now, the code should be doing exactly the same thing after you’re done refactoring. Then, you can switch your hat and go back to fixing the implementation.”

The book mentions great ideas for dealing with the common problems of refactoring. These problems include:

How do we not let it slow down development,
How should we arrange our code ownership for a suitable environment for refactoring,
How do we deal with legacy code base,
How to make use of branches in the version control systems,
How to deal with database involving refactorings.

I will not go into the details of these ideas. It is better to use them as a reference and refer to those sections when we face those problems.

Conclusion

Thank you for reading, that’s all for Part 2! I hope you find these points as useful as I do. And, stay tuned for Part 3!

My Top Takeaways From Refactoring: Part 1

2022-01-22T00:00:00+00:00

As software developers we should embrace change. Frameworks change, requirements change, expectations change… Incorporating those changes into the existing code base is not always easy. But, writing clean and well-structured code will make it easier for your future self.

As developers and designer, or even as humans, we do not always make the best decision in the beginning. Sometimes it helps to see where this journey is taking us and then we revise our previous decisions. The more considerate we are for those future revisions the easier it will be to apply them when the time comes. It is almost always the case for software development. Refactoring is the way we revise our past decisions for our software.

I would like to share my top takeaways from the book Refactoring by Kent Beck and Martin Fowler. The book shares invaluable practical ideas about refactoring. There is also a catalog of many refactoring techniques illustrated with amazing examples. Definitely recommend reading the book to anyone interested in learning more about refactoring.

Chapter 1 - Refactoring, a First Example

The first chapter is an example of refactoring in action. It justifies the actions taken and shares many useful rule of thumbs.

1. Aim to Embrace Change

The idea that the software we code is dynamic brings the implicit necessity to change. To apply the next change with ease we first need to have a good structure in place. Refactoring aims to improve structure of the code without effecting any observable functionality.

2. Make Sure You Have Enough Tests Before Refactoring

When refactoring the code we want to make sure the software keeps working as expected. The best way to achieve this is with the help of a good set of tests. Tests ensure that no matter what we change the functionality remains the same. We must make sure that our tests cover the areas we touch during refactoring. If they do not, we must stop now, and start adding those tests before even starting to rename a single method.

3. Refactor in Small Steps

Refactoring may break things and this is why we wrote the tests first, right? Right? Okay. We should make changes in steps as small as possible and test those changes. This way we know what and when we messed up and it is easier to revert as our step was small.

4. Have a System: Refactor, Test, Commit

No matter how careful we are, having a system when refactoring will help with the process.

When you refactor, you refactor in small steps. You test your change. Finally, you commit that change into your favorite version control system. Now you have a clear history of well tested changes! Thanks to this process, you can:

Revert to any of those commits with 100% confidence,
Stop whenever you like and release any commit and it will be an improvement, and,
You can squash those tiny commits into a larger more meaningful commits for a good looking history!

5. First Refactor, Then Extend

Refactoring before adding a new functionality will help with the thought process. And leaving the code base better than you have found it is a bonus!

6. Use Descriptive Names when Renaming

Renaming is a crucial technique in refactoring. Renaming variables, renaming methods, renaming classes… The point of renaming should be to use descriptive names that saves us time. A good name for a variable saves us from reading how it got here to understand what value it holds. A good name for a method saves us from reading its entire implementation to understand what it does. A good name for a class saves us from reading its entirety to understand its responsibility.

Spending a good amount of time and effort to choose a name is at the heart of refactoring. Otherwise, what would be the point of splitting a large method if we still had to read the smaller ones?

7. Keep an Eye on Performance when Refactoring

Performance might get effected during the refactoring process. Even if it does, it usually does in small scales with no significant loss. But, it is a good habit to take note of possible performance degrading points. After completing refactoring, we should review those points and fine tune for performance. It is going to be easier to fine tune as the code base will have a better structure at the end of refactoring.

Conclusion

Thanks for reading, that’s all for Chapter 1! I hope you find these points useful as I do. And, stay tuned for Chapter 2!

Docker Networking Explained With Example

2021-03-09T00:00:00+00:00

Most of our applications in production are multi-container applications. In a multi-container application, two or more containers work together as one to create a properly functioning application.

Imagine a web application with a backend, frontend, and database components that are all dockerized and work together to bring the web application to life! But how does the communication between these containers work?

Multi-Container Application Illustration

This post explains how multiple containers on a single host communicate with each other to form a properly functioning application. The term container networking is examined on a Spring Boot application that uses Redis as the data store.

Please check out GitHub for the source code.

Dockerized Spring Boot with Redis Demo Project Overview

Container Networking

By default, containers are isolated from each other by any means. But when it comes to communication, there’s a simple rule to that:

If two containers are on the same network, they can talk to each other. If they are not on the same network, then they can not talk to each other.

When we run docker network ls we get a similar response to the following:

NETWORK ID     NAME      DRIVER    SCOPE
878992be35ab   bridge    bridge    local
67416f902106   host      host      local
141ad47583f3   none      null      local

When we compose our application and then check with the same command, we will see an additional line in the response:

NETWORK ID     NAME                   DRIVER    SCOPE
878992be35ab   bridge                 bridge    local
67416f902106   host                   host      local
141ad47583f3   none                   null      local
fccef87cd248   spring-redis_default   bridge    local

When we get our application up and running, we also created a separate network for our containers to communicate through. But how do we that?

Docker Compose Networking

There are different ways to create a network for our containers to use. In our example, we use docker-compose to build and run our containers. When we call docker-compose up to start up our application, docker-compose creates a network, creates containers, and adds them to the network for services defined in docker-compose.yml.

version: "3.9"
services:
    web:
        build: ./springboot
        ports:
            - "8888:8080"
    containerizedredis:
        build: ./redis
        image: "redis:alpine"
        ports:
            - "16378:16379"

When we run docker-compose up providing the above configuration, what compose does is:

Create a new network and give it a default name (spring-redis_default)
As my “web” service, create a container using the configuration at ./springboot and add it to the network
As my “containerizedredis” service, create a container using the configuration at ./redis and add it to the network

The network name is set based on the directory name of your application. For example: spring-redis is the name of my directory and the network is called spring-redis_deafult.

Inspecting the Network

When our application is up and running, we can inspect the network to see that our containers have joined the network. To do so we are going to use the docker network inspect spring-redis_default command.

"Containers": {
    "ec23f91b6ab55e202080da5b62d8cf4c44f60001aebc618a410d279d915c674d": {
        "Name": "spring-redis_web_1",
        "EndpointID": "ba1753bcbdda6bbfda126b99223f2690155e0f80a7c57df53c5c04857f9e03c0",
        "MacAddress": "02:42:ac:12:00:02",
        "IPv4Address": "172.18.0.2/16",
        "IPv6Address": ""
    },
    "f02034324ffeaf8f4483265a3c0663e24f3982835512d4a5cf6c56e523ad6e4b": {
        "Name": "spring-redis_containerizedredis_1",
        "EndpointID": "1d148a1d0889a863e4cf506ea985c1149df6e7ba2f0fedba4a4607565067aea7",
        "MacAddress": "02:42:ac:12:00:03",
        "IPv4Address": "172.18.0.3/16",
        "IPv6Address": ""
    }
},

What we are looking for in the output is the Containers section. Here we can see that both of our containers (for redis and spring-boot) are joined to the network and now are able to communicate with each other!

Bridge Network

By default, a network called Docker Bridge Network is created, and all the containers are connected to that network if any other network is specified. Each container gets an internal IP address, and now all containers in that bridge can speak to one another. This provides an isolated network to the containers that live in a single host.

Docker Bridge Network Illustration

There are other network drivers such as Host and Overlay. By default, docker-compose creates a bridge network if any other driver is specified. Having a user-defined bridge network is better for isolation since all new containers are bound automatically when created without a “–network” flag.

Discoverability of Containers

In our case, our Spring Boot and Redis containers talk to each other to exchange information. They are already in the same network and have their IP addresses but, our Spring Boot Application is not using a static IP address to reach to Redis container but instead, it uses a hostname containerizedredis. Containers, like all other machines, use IP addresses at the end to communicate over the internet. The name “containerizedredis” is resolved to an IP address thanks to an A record created for it. We can examine the record with the help of another container that includes lots of useful debugging tools called nicolaka/netshoot. We will assign it to our new network “spring-redis_default” and run the container in interactive mode.

docker run -it --network spring-redis_default nicolaka/netshoot

Now let’s check out the record with the name containerizedredis:

$ dig containerizedredis

; <<>> DiG 9.16.11 <<>> containerizedredis
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62165
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;containerizedredis.		IN	A

;; ANSWER SECTION:
containerizedredis.	600	IN	A	172.18.0.3

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Sat Mar 06 10:20:39 UTC 2021
;; MSG SIZE  rcvd: 70

We can see in the response that there’s an A record for containerizedredis and it is resolved to an IP address 172.18.0.3. This means that whenever our Spring Boot application tries to access the host containerizedredis it is directed to 172,18.0.3.

Exposing Ports

Exposing the ports is not needed for the container to container communication. Exposing a port of a container means that the port is open to anyone as long as the host allows. Now that our containers can communicate with each other in an isolated environment, finally, it is time we talk to them.

In Docker Compose files, we define ports we want to expose with the following format: “HOST_PORT:CONTAINER_PORT”.

HOST_PORT is used when we want to specify which port to use to access the container from the host.
CONTAINER_PORT is used for container-to-container communication between services.

For example in our docker-compose.yml file, we set our ports as follows:

version: "3.9"
services:
    web:
        build: ./springboot
        ports:
            - "8888:8080"
    containerizedredis:
        build: ./redis
        image: "redis:alpine"
        ports:
            - "16379"

Here what we say is that:

Let the containers created with web service configuration communicate with other containers in the same network over its 8080 port, and let anyone reach out to these containers from the host’s 8888 port.
Let the containers created with containerizedredis service configuration communicate with other containers in the same network over its 16379 port, and it is not important which host port is assigned for outside communication.

So when we run docker ps what we see should be similar to what we have here:

CONTAINER ID   IMAGE              COMMAND                  CREATED          STATUS          PORTS                                NAMES
8f5b4ce0bf18   spring-redis_web   "java -jar /app.jar"     18 minutes ago   Up 18 minutes   0.0.0.0:8888->8080/tcp               spring-redis_web_1
804581c50507   redis:alpine       "docker-entrypoint.s…"   18 minutes ago   Up 18 minutes   6379/tcp, 0.0.0.0:55000->16379/tcp   spring-redis_containerizedredis_1

For spring-redis_web_1, port 8080 is exposed, and 0.0.0.0:8888 on the host machine accepts the requests and delivers them to the container. For spring-redis_containerizedredis_1, port 1679 is exposed and 55000 is given arbitrarily to deliver requests to that port on the host machine to the container.

You may ask why the port 6379 is listed to be exposed for redis container, even though we have not done it ourselves, it is because the redis:alpine image we use to build our container has the EXPOSE 6379 line in its Dockerfile.

Show Time!

Apparently, the encoding of Java’s UUID on the redis-server side was a bit weird, but you get the idea.

Docker Networking Demonstration

References

https://docs.docker.com/network/ https://docs.docker.com/compose/networking/ https://www.youtube.com/watch?v=PpyPa92r44s https://www.youtube.com/watch?v=Yr6-2ddhLVo

Cloud Computing Explained: Public vs. Private vs. Virtual Private

2021-02-01T00:00:00+00:00

Let’s talk about cloud in simpler terms!

Coming across different terms about a technology without actually getting your head around what they meant is a common issue. Recently, I decided to study Cloud Computing and I wanted start by learning the terminology and then diving deeper into the specific topics.

With the first post of the “Cloud Computing Explained” series, we will look at a small but commonly used subset of cloud terms:

Public Cloud
Private Cloud
Virtual Private Cloud

Let’s first look at the definitions, and then create an analogy to make them easy to remember!

Public Cloud

A Public Cloud is a set of cloud services provided to you and other customers by a vendor.

The Public Cloud enables us to provision resources on-demand according to our needs. There are many different vendors for public cloud services that offer you variant solutions based on your needs to build your software.

As these solutions’ levels go down, it gives you more control over the resource. However, this also means more overhead since you’ll have more things to do for that resource to be working reliably.

And one of the tremendous benefits of the public cloud is that you only pay for what you use. That gives you the ability to optimize your expenses.

Different Levels of Services

Take a look at the below diagram to visualize solutions at different levels. At the lowest level (bare-metal), you are the most flexible since you got all the control over your system. However, you also have to deal with almost everything by yourself, including scaling, monitoring and, deployment. On the highest level (Serverless, FaaS), you can concentrate solely on writing your application. You give up some of the flexibility for more convenience.

By Nate Schutta (Developer Advocate, Pivotal) at SpringOne Platform 2018

Private Cloud

The Private Cloud is having a public cloud environment on the infrastructure that is dedicated to you.

That brings the disadvantage of being limited by your infrastructure’s limits and the advantage of having no other neighbors to share your resources.

Virtual Private Cloud

A Virtual Private Cloud is where a public cloud’s resources are divided into virtually isolated divisions - “private clouds”.

Isolating each division from each other creates the illusion of customers have their private cloud - but it’s only there virtually. Virtual Private Clouds are similar to virtual machines where there are no actual physical machines but only the isolation of resources.

Virtual Private Clouds are a type of Hybrid Clouds. Virtual Private Clouds are a type of Hybrid Clouds.

Different Cloud Types Visualization

An Analogy

Imagine the public cloud as an internet cafe where they have these computers and charge you for the time you use them. In that case, the internet cafe is the vendor (in real life, this could be Amazon, Google, Microsoft, etc.). When you go and there and ask for a computer, they start your session on one of the available computers in the public area with others, using the same underlying infrastructure.

The private gaming rooms, in which they provide you an isolated internet connection from the ones in the public area and the other private gaming rooms. These rooms can be an analogy for virtual private clouds.

Let’s say this internet cafe vendor provides you the service to build one of these private gaming rooms at your house. They use your house’s infrastructure but with their computers and all the software in it. That would be the equivalent of a private cloud.

References

Welcome To My Blog!

2021-01-16T00:00:00+00:00

A warm welcome to you all!

Verba Volant, Scripta Manent! - Latin Proverb
Spoken words fly away, written words remain.

Hey, it’s Recep! You can learn more about me here in the “About” page!

I took the below three philosophies very seriously as I started my blog:

Verba Volant, Scripta Manent - Spoken words fly away, written words remain. I’ve always loved taking notes of the things I learned and writing documents for the things I’ve built because that’s what keeps the information accessible at any time. Although I digitalize most of my notes, pens and notebooks are still my favorites. :)
Teaching is the best teacher - To teach something to someone, you have to get into the subject in detail. Studying some topics is good but teaching them to others is a whole another thing. It helps with two things, you understand the topic better and enhance your communication skills.
Ideas worth spreading - I love sharing what I know with others via any medium, but writing has always been my first choice. The essential purpose of this blog is to make my knowledge easily accessible to anybody.

I hope you enjoy reading as much as I enjoy writing my blog.

To access my older posts please check out: http://medium.com/@recepinancc