Saving costs in the cloud with smarter caching - Part 1

A cache is a component where data is stored so that future requests can be served faster. So for example, in the context of a web application responding to multiple requests,  instead of hitting your backend database or microservice every time, the application can remember the last value for a given computation or call. One particular flavor is a centralized cache system, provided by tools like Redis, Memcached, etc. A central place where we store data temporarily and all instances of our app (and even other apps) can use it. There are many uses, from storing session data in a multi-server web application to providing a performance advantage by keeping a value that is costly to calculate or obtain.  A centralized cache is a lifesaver. But it tends to be overused and there are some scenarios where we could reduce its usage or completely skip it, and in doing so, save costs and improve performance.  Reducing the usage of the centralized cache. Let's have an example of a web app that

Hello Thanos: static web app with azure function

We are going to create a plain HTML+JS static web app with an Azure Function as backend API, and by "plain" I mean no framework like React, Angular, or Vue, but will use Bootstrap and JQuery. It will be a simple app with  2 input fields and 1 button. You will enter your name and last name and the app will say "hello" to Thanos and let you know if Thanos snapped you or not (Because you should not talk to the mad titan without permission). We are going to use ReCaptcha V3 to prevent abuse and a bootstrap form with client-side validation before sending the data back to the azure function. #1 Create the app from Visual Studio Code Let's create a "custom" framework static web app following these instructions , then add a /src folder and place a basic index.html file there with the text "hello world". Just make sure you use /src as "source path" and leave "build path" empty. You can confirm paths are correct by opening the GitHu

The case for a 4 week sprint

Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t

Emergent Architecture is not a thing

Emergent architecture is a term I heard for the first time from a coworker a while ago. It was touted as a combination of agile and architecture, or perhaps as the way the shiny term "architecture" was inserted into something as face paced as Scrum, or as a way for the company justify not having architects, but to put it plainly, it's not a thing. There are a few things wrong with it... conceptually.  I have read a lot about it, looking for any source of information I could, presentations, blogs, some links here and there, and I could not find a solid base for what they claimed it was, or any reason for it to be claimed as a thing, except for the need to name something with "architecture" on it. Agile is a methodology, Scrum is a method, if you want to know a bit more about the difference just hit Wikipedia . They are related to  how to build software.  Now, architecture, is about structure, is about what you build. You can reach that structure with any me

NET Core, Java and Open Source

We need to talk about it How open is .NET Core and C#? How does it compare to a platform like Java? Well... let's see. Disclaimer: The post is a resumed version with lots of links, so be prepared to read it in a DFS or BFS way :)  .NET Core In November 2014, The Microsoft team announced that " NET Core is Open Source " Included C# and Visual Basic compilers Visual F#   ASP.NET Core Entity Framework Core NET Core Framework   In 2015, Microsoft releases Visual Studio Code , a cross-platform multi-language IDE.  All these released under an Open Source license. The MIT License . NET Core runs in Windows, Linux, Mac and ARM-based systems (IoT) Docker support existing Java Originally made open source by Sun in 2006 Released under GPLv2 CE license . The CE clause allows it to be used in a more restrictive scenario.  Oracle has a different licensing schema for "Enterprise Java". While the OpenJDK is still safe (and should remain so) Ente

The distributed monolith antipattern

The words distributed and monolith are usually adversaries in software architecture, contrary to the monolith model,  a distributed approach will allow you to have isolated services as building blocks of functionality for your system. Let's assume you reached that architecture already, either from scratch or by decomposing an existing monolith. At this point you have a set of services.  Some people go and just say - "it's microservices!". Well..., that's not enough yet, but now you have all the pieces into individual services and the whole system working together.  This is a step into the right direction for scalability, but we can do more in other areas.  So, let's check: how do you deploy them ? If you deploy all services at once , you still have a lot to improve, for now you have a "distributed monolith" (Open to a better name for this), which I consider to be an antipattern, and this is more of a common practice than expected,

Playing with strings and performance in C#

A few weeks ago, I was solving a problem at HackerRank and after completing a solution that ran  under 100 milliseconds, the program would still timeout during execution. HackerRank limit is usually 1 second, so something was taking more than 900ms. It was the strings! Yes, we know handling strings is costly, but this time there was no way around it.  At the final stage of the problem I had to construct a string over 200k chars long from an array of Boolean values that represented the bits of the number.   Disclaimer : Strings are slow, mainly because they are immutable. Concatenating two strings, creates a third one and possibly 2 for the garbage collector to pickup. Looking through the code I noticed I was simply using " += " instead of StringBuilder.Append method. After using StringBuilder the solution was faster and the submission was approved. It was  fast now, but it got me thinking "how much faster indeed?" which ended with me measuring the perfor