##Why I chose this post
This post caught my attention as I was scrolling through Uwe Friedrichsen’s list of blogs. It had API in its subtitle and since we had covered RESTful API’s in class I though this would be a great opportunity to see his approach to API design. After scanning through the blog I saw the term concept spill which I had not heard before and I thought it would be interesting to learn something new about API through the lens of an experienced IT specialist.

##Summary of the post
The author begins by talking about how by taking technologies and fitting them into the entire system might work easily but we end up missing the important aspect of fully fullfilling the users needs. He introduces a concept AX which reffers to APIeXperience as to how the programmer will be able to work with an API design to fulfill the requirements of his users. Similar to UX in application design, a good AX might breed good results on the operational and functional side of a system or system software. He then introduces concept spill which is one of the factors that might reduce the AX of a programmer.

He defines concept spill as a situation where, “in order to use another service to solve your acutal problem, you first need to understand its internal concepts.” He gives a good example of how you would have to understand a city’s transport systems, such as zones, bus and train stops etc., when you want to move from one point to another in a new city. You are force to understand the city’s layout before you solve your initial problem of going to a particular place within the city, concept spill.

Concept spill pours over into the IT world in API design where a programmer is forced to learn how the creators of the API came up with the API’s stucture and inner workings on top of the issue that he is trying to solve. How do we solve the problem of concept spill? At the root of avoiding concept spill is to understand the user’s needs and design your API to cater for the user’s needs. An API designed without the user’s context/story in mind will lead to poor operations of the API thus futher complications. Understand common uses of the API and base your design on these uses.

##Reflection and Application
The blog post offered good advice on how to make API more user based which makes good design and acceptance by developers. Even as I look forward to working on my software capstone next semester, I think this will be great to put in mind as we work on improving Thea’s Pantry.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Why I chose this post

I chose this post because the author touches on an important topic, resilience, which is a term that I have heard before in relation to IT related fields but I have never really taken time to understand it or even know how it is applied. Again Uwe Friedrichsen gives relevant examples as he covers this topic. He gives examples both within the IT sphere and some examples outside IT making resilience as a concept easier to understand.

Summary of post

The author begins by defining resilience, “resilience means that a system can ideally withstand adverse external influences completely or at least recover from them quickly.” Adverse effects can range anywhere from external influences from illness, overload situation, a pandemic, extreme weather and so on.

Friedrichsen gives an example of how the COVID-19 pandemic affected German car manufacturers. Since they had found an efficent way of procuring car parts, they became dependetn on chip makers in Taiwan. And in a figure of speech he says that, “ they have put all their money on a single horse and expect that this horse will always be the first to cross the finish line. And their calculation already includes the prize money for the horse.” This show how reliant car manufacturers had become dependent on Taiwanesse chip makers. However, when COVID hit the supply chain was greatly affected.

The author then shows the delicate balance that exists between efficiency and resilience, he also shows that a highly efficient systems is also very highly rigid. A balance must exist by reducing the efficiency in order to maximize on th resilience of a system. In the post industrial world the author says that he has witnessed a lot of uncertainity and full control of varience has become hard. We should therefore as early as we could begin to embrace the fact that there might be adverse situations down the road

Reflections and application

The blog offers a lot of important advice for the age and time that we live in. Due to the inconsistent nature of systems and resources in the world we live in today it is foolish to be single minded, despite the security that you may enjoy for the brief period when disaster strikes it will be hard to recover.

In my personal life and even in my career, this will be an important principle to live by.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Why I chose this post

I chose this post because I find that Uwe Friedrichsen’s insights are usually revealing and an accurate description of what I am to encounter in my work life. This topic, surrounding ACID consistency, is also closely related with software architecture as most systems work in unison nowadays due to the structure of microservices in most systems. Above all he gives real life examples that support his claims in a logical and meaningful manner. His structure of developing arguments with more than one blog post is also great as it slowly build up claims with good evidences and examples.

Summary of post

Friedrichsen begins by introducing the concept of eventual consistency and compares it to strong consistency. He talks about an example of money transfer between two people and how it takes time for the money to reflect on the recipients account. Strong consistency would mean that immediately the money is transferred there would be a reception on the recipients end, however, eventual consistency is what we have where after a while where the money eventually reflects after a period time.

The author again gives another example of how strong consistency is non-existent. In this example a clerk gets called by a customer who needs some infomation, the clerk retrieves data need to answer the question and gets it displated on the screen. As he goes through the information before he answers the customer the data changes and the author poses a question,”Will the answer of the clerk be based on the current data? Or will the answer be based on the old data that was valid until some seconds ago but is invalid now?” This again show the incosistent nature of data and therefore the non-existence of a strongly consistent system.

Reflections and application

The author makes a valid argument on the non-existence of strong consistency. I understood the difference between strong and eventual consistency. I also realized that all systems today run on eventual consistency. We do not have a guarantee of the outcome but it is after time that we eventually get consistency.

This concept reminds me that we can never achieve perfection and reminds me that progress matters more than perfection not only in our careers but in our daily lives as well. So as I work on projects invlolving systems I would focus more on having the individual parts communicate and then gradually improve their performance as time progresses.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Why I chose this post

I selected the blog as the author who has years of experience again highlight a key barrier that exists within distributed systems which can mirror microservices architecture. The two have to independent but interdependent qualities and a change to one part of the system will likely affect the entire system. The blog also addresses architecture of systems which is key in considering the design and the policies that are to be implemented across a number of systems.The author also has a good scientific approaches as to how to determine the success rate of an update upon a number of systems as well the breakdown as to how he arrived at such conclusions.

Summary of the post

The author introduces the concept of ACID consistency in business where a change in one part of a system should reflect across all other parts of the business. ACID is defined as the atomicity, consistency, isolation and durability and it is mostly implemented in database transactions to ensure data validity despite errors, power failures and other mishaps. Atomicity guarantees that each transaction is treated as a single unit that succeeds completly or fails completely. Consistency ensures that a transaction can only bring the database from one consistency state to another. Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially. Finally, durability gurantees that once a transaction has been committed, it will remain committed even in the case of a system failure. The author focuses on why it is important that consistency is established across multiple systems. Considering the number of applications that companies use in the world today, along with the number of paths of communication in these organizations, establishing consistency is an uphill task. “The more systems involved the higher the chance of a failure.” In comparison with older systems when may of the connections were batch-type, the systems today which have online communicaition paths are more prone to errors. Batch-type systems were considered to be more more tolerant.

Reflections and application

Again Friedrichsen offers good insight as to how hard it is to establish consistency across multiple distributed systems. Considering factors such as down time and the success rate when carrying out updates, establising consistency becomes a challenging task, I look forward to seeing some of the solutions or ways of ensuring consistency that he offers in the following blog as I believe that this is a huge challenge that most businesses face today. I have learnt that establishing consistency within systems is vital but it prooves challenging as the number of systems and communication paths between them grow.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Why I chose this post

As we have progressed with the course material we have seen the advantages that microsystems have over monolithic structured systems. These advantages have shown to overcome most of the limitations that monolithic structures exhibited. However, microsystems or distributed softwares have some short comings of their own. In this blog the author focuses on some of the errors that may arise within a distributed software.This would shed some light on some of the cons of microsystems.

Summary of the post

The author begins by speaking about the 100% availablity trap which most developers fall into. This trap is where developers, “ assume that all remote peers, icluding infrastructure tools like databases, message brokers and alike , are available 100% of the time, i.e., that they are never down.” The author breaks down why a distributed system cannot be available for 100% of the time. A system is not available if it does not respond, responds slower that specified or provides a wrong response. The author then mentions the “nines” which looks at what a 90% and above availability looks like for a distributed system. To get to these levels of availability there is a lot of consideration that goes into play, from patch and maintenance days to managing test and runtime which will drastically increase to achieve this level of availablity. Not forgetting the costs and efforts.

The author then alludes to the fact that with increasing number of nodes there is an expected decrease in the availability of the system as well. Also another factor to cosnsider is the network that facilitates communication between the nodes. The network must be in perfect condition to ensure perfect availability which is very hard to actualize.

Finally the author ends with this statement. “The question is not, if failures will hit you in a distributed system landscape.The only question left is, when and how bad they will hit you.”

Reflections and application

Despite the countless number of advantages that a distributed system has, I have realized that they cannot achieve perfection. “Every dog has its own fleas.” The author has clearly shown me how this is true. The final remark that he has also brings in a perspective of always being ready to experience an issue. These concepts that I have learnt I’m sure will prove valuable and important in my career life and even as I work on projects that involve microservices.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Why I chose this post

Considering the experience of the author, Uwe Friedrichsen, who is a CTO at codecentric along with years of experience. I was intrigued why he would write a blog series on the topic of resilience in software design. I figured that this would be a key concept in designing software and therefore I decided to read the blog. As I read through the blog the author mentioned concepts that we would be covering in class such as API and other new concepts such as service meshes which motivated me to read more.

Summary of the post

The author begins by defining what resilience is. He defines it as keeping correct operation in the face of unexpected events or at least recovering from them in a timely manner, while offering a gracefully degraded service in the interim. He then goes into a quick run through of how the matter of resilience was left to the operations teams in the past.

Developers would develop software with an apporach that it was running a single process on a single machine that will never fail. Nowadays, container schedulers are making sure a specified number of replicas are active, service meshes offering timeout and monitoring automatic retries along with API gateways taking care of rate limiting and failover showing that the concept is still prevalent.

Friedrichsen then shows how distributed systems came to change the whole mentality of “running a single process on a single machine that will never fail”. He explains this With an example of how batch processes took the place of data typists and eventually became overtaken due to the internet and remote procedure calls (RPC). He goes on futher to show that the increase of the number of devices in the Iot has led to an increased number of peers on the systems leading to further implementation of distributed systems. He concludes by speaking about how softwares are running 24/7 which puts more need on the dependance of distributed systems.

Reflections and application

Being the first part of the blog series, the author introduces the importance of distributed systems and shows its growth through history well. I personally learnt how important distributed systems are in running most of the softwares that we run today, conisering that fridges can now be part of the internet. As we begin the process of learning how to design software I will keep this principle in the back of my mind that resilience is important in software construction.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

Dawn

First rays coming through. I had been wanting to start my own blog for a while now. Procastination took the better part of me. But finally the sunrise is coming out!

A blog was required for one of my classes and I took this as an opportunity to nudge myself to starting this blog. The class Software Construction, Design and Architecture seems to be a promising one, pushing me out of my comfort zone already.

On top of that, the class involves application from most of the classes that I have taken before. It is therefore a good opportunity put into action skills and ideas that I have taken up from classes before. Like a chef picking out the finest ingridients to make a scrumptous meal.

Tags

I have not learnt how to tag the blogs yet, but I am hoping that with time I will be able to do so.

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.