Skip to main content

Posts

Are we DevOps, or SRE?

SRE Vs. DevOps has been a ranging battle for quite sometime now. Ask any operations or infra team in today's bubbling tech shops and, they will tell you, without a flutter, that they are SRE. Scratch them a bit more and, they will tell you how they follow the SRE principles with stories from their daily grind and link them to Google's SRE handbooks. Then drop the big question, "But isn't the same thing DevOps too?" and see them getting confused and incoherent a bit. Now, if you ask, "Or maybe, yours is more of a hybrid model than pure DevOps/SRE?". Now, you might have turned a few heads and even made some ponder further away. Managing "Operations" as a disciplined practice has always been an arduous task. Many companies today have dedicated operations departments engaged in planning and executions, but more often than not, they fail badly. The tech operations landscape is no different. There are always, generally unsolved questions about how t
Recent posts

Does Linux Need a Defragmentor?

In computing terminology, file system fragmentation sometimes also called file system aging, is the inability of a file system to lay out related data pieces sequentially or contiguously on the disk storage media. This is an inherent problem in storage-backed file systems that allow in-place or live modification of their contents. This is one of the primary use cases of data fragmentation.  File system fragmentation increases disk head movement or seeks required for fetching the whole file, which are known to hinder throughput and performance of disk reads and writes. As a remedial action, the motive is to reorganize files and free space back into contiguous areas or blocks so as to keep all pieces of a file data together at one place, a process called defragmentation. Ok, give me an example please? let's attempt at explaining in a simple, non-technical manner as to why some file systems suffer more from fragmentation than others. Rather than simply stumble through lots of dry te

Concurrency in Java – Series

Concurrency and parallelism features in Java are as old as Java itself. The original creators and specification authors rightly presumed that programmers and future state software designs would need high concurrency capabilities to scale their apps. The Java Memory Model and the JVMs are designed from the ground up to support concurrent programming, with basic concurrency support built in the Java programming language and the Java class libraries. Since version 5.0, the Java platform has also included high-level concurrency APIs to ease the complex semantics of working with and understanding Threading behaviors. This series outlines the core concepts of concurrency in Java and provides a balanced view from the JVM memory model specifications as well as from the programmer's perspective. The series discusses important principles and provides guidance about designing concurrent applications in Java. The series is divided into following easy to follow posts:  Part 1 - The Stepping Sto

Concurrency in Java – Part 1, The Stepping Stones

What are Threads? Conceptually, a thread is a distinct flow of control within a program. A thread is similar to the more familiar notion of a process, except that multiple threads within the same application share much of the same state, in particular, they run in the same address space or memory space. Sharing the address space between threads has a big advantage as it allows the reuse of the same data space between threads. If we had a separate small data stack, local to each thread, then data sharing and data synchronization can become a big problem in programs. This is essentially the same situation that we encounter related to Session state sharing across JVM clusters in production clustered environments. Distinct address spaces would require a complex mechanism to share the mutable state across thread spaces as soon as the thread mutates its local address space. In essence, it would require address space synchronization mechani

Concurrency in Java – Part 2, Object behavior heuristics

This post is the part 2 story in the Concurrency in Java – Series that touches the core concepts of concurrency in Java and provides a balanced view from the JVM memory model specifications as well as from the programmer's perspective. To see the list of posts in this series, please visit here . ----------------********---------------- In the previous post, we saw the following sample code that  shows a typical use of synchronized thread safe idiom. EmployeeManager2  is a simple example about how to make use of thread safe constructs without compromising on concurrency. However as the programs evolve in size, the problem of thread safe also increases exponentially. e.g. assume that we have to calculate an employee’s total CTC package and tax structures also and should be available for reading once the employee is loaded in the list. One way to do it is to have the individual components of the C

Concurrency in Java – Part 3, State Visibility Guarantees

This post is the part 3 story in the  Concurrency in Java – Series  that touches the core concepts of concurrency in Java and provides a balanced view from the JVM memory model specifications as well as from the programmer's perspective. To see the list of posts in this series, please visit  here . ----------------********---------------- In the previous post , we discussed at length about the object behaviour heuristics. In this installment of the series we shall try to examine the common State Visibility Guarantees that we get from the JVM specification and JVM implementations. Locking idioms not just help us in controlling access around program ‘critical paths’ but also allows us to coordinate access and guarantee consistency and durability of state visibility operations. This is an important consideration that JVM specification offers as a subtle guarantee. Without this guarantee, there would actually be little or no sense

Concurrency in Java – Part 4, Design Thread Safe Classes and Components

This post is the part 4 story in the  Concurrency in Java – Series  that touches the core concepts of concurrency in Java and provides a balanced view from the JVM memory model specifications as well as from the programmer's perspective. To see the list of posts in this series, please visit  here . ----------------********---------------- In the  previous post , we discussed the two State Visibility Guarantees that Java Memory model offers to its practitioners. In this episode of the Concurrency in Java series we shall have an exhaustive discussion about the various critical guidelines that we need to follow when designing thread safe concurrent Java applications. Design Thread Safe Classes and Components Designing thread-safe classes is not a herculean task but rather a simple 'play by the book' set of rules to be followed and adhered to. This section outlines a set of basic guidelines to follow to design