Around IT in 256 seconds
Podcast for developers, testers, SREs... and their managers. I explain complex and convoluted technologies in a clear way, avoiding buzzwords and hype. Never longer than 4 minutes and 16 seconds. Because software development does not require hours of lectures, dev advocates' slide decks and hand waving. For those of you, who want to combat FOMO, while brushing your teeth. 256 seconds is plenty of time. If I can't explain something within this time frame, it's either too complex, or I don't understand it myself.
By Tomasz Nurkiewicz. Java Champion, CTO, trainer, O'Reilly author, blogger
Kategorie:
Technologia
Technologia
#37: Fallacies of distributed computing
2021-03-23 00:22:04
Fallacies of distributed computing are a set of myths we believe, when designing complex systems. And what is a distributed system? Well, if your application is split into hundreds of microservices, it’s distributed. Or if you have a single application, scaled horizontally to hundreds of instances. Or… If you have a monolith connecting to a database on the other node. This is a distributed system as well! OK, we have 200 seconds left and 8 fallacies to cover. Let’s go!
Read more: https://256.nurkiewicz.com/37
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
Fallacies of distributed computing are a set of myths we believe, when designing complex systems. And what is a distributed system? Well, if your application is split into hundreds of microservices, it’s distributed. Or if you have a single application, scaled horizontally to hundreds of instances. Or… If you have a monolith connecting to a database on the other node. This is a distributed system as well! OK, we have 200 seconds left and 8 fallacies to cover. Let’s go!
Read more: https://256.nurkiewicz.com/37
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#36: Microservices architecture: principles and how to break them
2021-03-16 01:26:42
Microservices are contrasted to a monolith. Single, large application that implement the whole system. Typically hard to understand, develop, test and deploy. Monoliths tend to become a big ball of mud with each component referencing every other. The idea behind microservices is to split your complex system into multiple independent applications. Small and agile. They communicate with each other via APIs but are otherwise highly decoupled. The independence and decoupling has many aspects: deployment, languages and frameworks, storage, organization. Most importantly, each microservice should be self-sufficient to a reasonable degree. Let’s discuss what it means and how often these aspects are violated.
Read more: https://256.nurkiewicz.com/36
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
Microservices are contrasted to a monolith. Single, large application that implement the whole system. Typically hard to understand, develop, test and deploy. Monoliths tend to become a big ball of mud with each component referencing every other. The idea behind microservices is to split your complex system into multiple independent applications. Small and agile. They communicate with each other via APIs but are otherwise highly decoupled. The independence and decoupling has many aspects: deployment, languages and frameworks, storage, organization. Most importantly, each microservice should be self-sufficient to a reasonable degree. Let’s discuss what it means and how often these aspects are violated.
Read more: https://256.nurkiewicz.com/36
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#35: Reactive programming: from spreadsheets to modern web frameworks
2021-03-02 09:19:46
To understand what reactive programming is, let’s contrast it to imperative programming. Imperative programs can be read top-to-bottom, with occasional jumps. Jumps are if statements, loops and procedure calls. Program is executed line by line. If you see x = y + z , the expression on the right is evaluated once. Then the symbol on the left is modified. If you change the value of y or z in the next line, obviously, it won’t affect x . Compare it to a spreadsheet. Yes, an Excel file. It’s obvious that changing any cell immediately propagates to all cells that depend on it, right? The process continues until all affected cells are updated. Essentially, every spreadsheet is internally represented by a dependency graph. We declare which pieces of data depend on which. The rest happens automatically. This approach to developing software is called… reactive programming .
Read more: https://256.nurkiewicz.com/35
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
To understand what reactive programming is, let’s contrast it to imperative programming. Imperative programs can be read top-to-bottom, with occasional jumps. Jumps are if statements, loops and procedure calls. Program is executed line by line. If you see x = y + z, the expression on the right is evaluated once. Then the symbol on the left is modified. If you change the value of y or z in the next line, obviously, it won’t affect x. Compare it to a spreadsheet. Yes, an Excel file. It’s obvious that changing any cell immediately propagates to all cells that depend on it, right? The process continues until all affected cells are updated. Essentially, every spreadsheet is internally represented by a dependency graph. We declare which pieces of data depend on which. The rest happens automatically. This approach to developing software is called… reactive programming.
Read more: https://256.nurkiewicz.com/35
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#34: SQL joins
2021-02-23 00:00:00
In relational databases, data is kept in relations, commonly known as tables. Simplifying, when data is normalized, it’s not duplicated. For example, when storing books and authors, you don’t keep an author’s name next to a book record. Instead, you use a so-called foreign key that references the author in another table. Thanks to this level of indirection, books by the same author do not store repeated information. This has many benefits and one, huge drawback. In order to look up a book together with a corresponding author you must somehow correlate these two tables. This is called joining.
Read more: https://256.nurkiewicz.com/34
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
In relational databases, data is kept in relations, commonly known as tables. Simplifying, when data is normalized, it’s not duplicated. For example, when storing books and authors, you don’t keep an author’s name next to a book record. Instead, you use a so-called foreign key that references the author in another table. Thanks to this level of indirection, books by the same author do not store repeated information. This has many benefits and one, huge drawback. In order to look up a book together with a corresponding author you must somehow correlate these two tables. This is called joining.
Read more: https://256.nurkiewicz.com/34
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#33: OAuth 2.0
2021-02-16 01:02:49
OAuth 2.0 is a standardized authorization protocol. In this episode, I’ll explain just one use case of it: the authorization code flow. It allows server-side application to act on behalf of a user of another service. For example, a 3rd party application can post on Twitter on your account. Historically, to do this, this application must have had your Twitter credentials stored. Not only you had to reveal your Twitter password, but also that application must store it in plain text. Such an approach has multiple flaws. First of all, if the application is not entirely honest, it can now do anything on your behalf. Including changing your password and stealing your online account. But even if you trust the 3rd party application, it can still be hacked. Your password, together with thousands or millions of others, is compromised.
Read more: https://256.nurkiewicz.com/33
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
OAuth 2.0 is a standardized authorization protocol. In this episode, I’ll explain just one use case of it: the authorization code flow. It allows server-side application to act on behalf of a user of another service. For example, a 3rd party application can post on Twitter on your account. Historically, to do this, this application must have had your Twitter credentials stored. Not only you had to reveal your Twitter password, but also that application must store it in plain text. Such an approach has multiple flaws. First of all, if the application is not entirely honest, it can now do anything on your behalf. Including changing your password and stealing your online account. But even if you trust the 3rd party application, it can still be hacked. Your password, together with thousands or millions of others, is compromised.
Read more: https://256.nurkiewicz.com/33
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#32: (Cryptographic) hash function
2021-02-09 00:00:00
Sometimes you need to split arbitrary objects into a fixed number of groups. For example, storing a record into one out of many database nodes. Or saving a cookie in a hash table. Or distributing jobs among multiple workers. In all of these cases you later want to know, bucket or worker was chosen. Also, data should be split evenly. You don’t want one node or worker to be overloaded. The above properties are implemented by a so-called hash function. It’s an algorithm that takes arbitrary input and produces fixed-length output. A number. For the same input, often called a message , it always produces the same output, known as a hash. Ideally, different messages should produce a different hash. Even better, two slightly different messages should produce wildly different hash. In practice, hash collisions must happen. After all, we are mapping arbitrarily large messages into a fixed-length hash. Often 32- or 64-bit.
Read more: https://256.nurkiewicz.com/32
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
Sometimes you need to split arbitrary objects into a fixed number of groups. For example, storing a record into one out of many database nodes. Or saving a cookie in a hash table. Or distributing jobs among multiple workers. In all of these cases you later want to know, bucket or worker was chosen. Also, data should be split evenly. You don’t want one node or worker to be overloaded. The above properties are implemented by a so-called hash function. It’s an algorithm that takes arbitrary input and produces fixed-length output. A number. For the same input, often called a message, it always produces the same output, known as a hash. Ideally, different messages should produce a different hash. Even better, two slightly different messages should produce wildly different hash. In practice, hash collisions must happen. After all, we are mapping arbitrarily large messages into a fixed-length hash. Often 32- or 64-bit.
Read more: https://256.nurkiewicz.com/32
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#31: Redis
2021-02-02 00:00:00
Redis is quite a versatile NoSQL, key-value database. Or in-memory cache. Or pub/sub broker. With transactions, stored procedures and fast replication. It’s quite universal. Anyway, the main use-case for Redis is caching. Internally the whole dataset must fit in memory. Redis can optionally persist data on disk, but all online operations happen entirely in memory. This makes Redis extremely fast. It’s often used as an alternative to the widespread Memcached server.
Read more: https://256.nurkiewicz.com/31
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
Redis is quite a versatile NoSQL, key-value database. Or in-memory cache. Or pub/sub broker. With transactions, stored procedures and fast replication. It’s quite universal. Anyway, the main use-case for Redis is caching. Internally the whole dataset must fit in memory. Redis can optionally persist data on disk, but all online operations happen entirely in memory. This makes Redis extremely fast. It’s often used as an alternative to the widespread Memcached server.
Read more: https://256.nurkiewicz.com/31
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#30: Linear Regression
2021-01-19 00:10:29
Linear regression is one of the simplest machine learning algorithms. But also quite useful. It takes a bunch of existing, known observations and tries to predict how new observations will look like. Think about forecasting or finding trends. It says “ linear ” because the algorithm essentially finds a straight line that most closely follows the observations. OK, let’s take a concrete example. Imagine you are selling your apartment. What is the right price for it? Well, you compare it to similar apartments in your neighborhood. If someone sells the exact same flat across the street, your price should be very similar. If another flat is sold, but 10% larger, expect its price to be 10% higher as well. Yet another flat is half the size of yours. So expect its price to be just 50% of your estimated asking price. Sounds reasonable?
Read more: https://256.nurkiewicz.com/30
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
Linear regression is one of the simplest machine learning algorithms. But also quite useful. It takes a bunch of existing, known observations and tries to predict how new observations will look like. Think about forecasting or finding trends. It says “linear” because the algorithm essentially finds a straight line that most closely follows the observations. OK, let’s take a concrete example. Imagine you are selling your apartment. What is the right price for it? Well, you compare it to similar apartments in your neighborhood. If someone sells the exact same flat across the street, your price should be very similar. If another flat is sold, but 10% larger, expect its price to be 10% higher as well. Yet another flat is half the size of yours. So expect its price to be just 50% of your estimated asking price. Sounds reasonable?
Read more: https://256.nurkiewicz.com/30
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#29: Time synchronization
2021-01-12 01:24:36
Clocks are important to computers. Computers need to order events in a way understandable to humans. Every computer has a bunch of internal counters, like CPU ticks. But they only work within one machine. We need a way to have a reliable, global clock, that is synchronized between many computers. Why, exactly? Well, imagine you are selling tickets to The Rolling Stones concert. They sometimes sell within a few seconds. First come, first served. But who was first, if selling happens asynchronously in multiple data centers? Fans shouldn’t be penalized for being routed to a server with higher latency. So, instead, we use timestamps. Late messages may still be treated as earlier ones if a transaction timestamp says so. Obviously we can’t rely on the client’s clock. It’s too easy to change your laptop’s time and see Mick Jagger from the front row. But how do we make sure servers aren’t lying the same way? Even unintentionally? This is where NTP, network time protocol, comes into play.
Read more: https://256.nurkiewicz.com/29
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
Clocks are important to computers. Computers need to order events in a way understandable to humans. Every computer has a bunch of internal counters, like CPU ticks. But they only work within one machine. We need a way to have a reliable, global clock, that is synchronized between many computers. Why, exactly? Well, imagine you are selling tickets to The Rolling Stones concert. They sometimes sell within a few seconds. First come, first served. But who was first, if selling happens asynchronously in multiple data centers? Fans shouldn’t be penalized for being routed to a server with higher latency. So, instead, we use timestamps. Late messages may still be treated as earlier ones if a transaction timestamp says so. Obviously we can’t rely on the client’s clock. It’s too easy to change your laptop’s time and see Mick Jagger from the front row. But how do we make sure servers aren’t lying the same way? Even unintentionally? This is where NTP, network time protocol, comes into play.
Read more: https://256.nurkiewicz.com/29
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
#28: Event sourcing
2021-01-05 01:20:29
Event sourcing is an alternative technique of storing business data. Rather than updating a single database record, every change is captured in an immutable, append-only log. We never overwrite existing data. Instead, we create and store an event that represents what exactly has changed. From the business perspective. In order to recreate the current state of an entity we must go through all the events and reconstruct it from history. Event sourcing brings better auditing and debugging. Also, storing changes can be faster because it requires inserting a new record rather than updating an existing one.
Read more: https://256.nurkiewicz.com/28
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter
Event sourcing is an alternative technique of storing business data. Rather than updating a single database record, every change is captured in an immutable, append-only log. We never overwrite existing data. Instead, we create and store an event that represents what exactly has changed. From the business perspective. In order to recreate the current state of an entity we must go through all the events and reconstruct it from history. Event sourcing brings better auditing and debugging. Also, storing changes can be faster because it requires inserting a new record rather than updating an existing one.
Read more: https://256.nurkiewicz.com/28
Get the new episode straight to your mailbox: https://256.nurkiewicz.com/newsletter